[SP-pm] Resumo do Evento Técnico

Fri Jan 30 18:55:03 PST 2015

Em 30 de janeiro de 2015 01:58, Solli Honorio <shonorio at gmail.com> escreveu:

>
> Continuo não entendendo esta afirmação de que REST só serve para poucos.
> Neste exato momento temos bilhões de dispositivos móveis executando
> centenas de bilhões de transações de milhares de aplicativos diferentes. Se
> isto significa que esta arquitetura é para um nicho, então não sei o que é
> uma arquitetura para a massa.
>

Qdo eu falo que é para poucos, não é que dá para contar nos dedos das mãos,
mas que no universo de milhões de servidores e serviços web (servidores;
não clientes), nem todo mundo precisa comer a bolacha stateless, nem usar a
semântica HTTP (POST, PUT etc)

No documento que o Blabos mandou, as vantagens citadas são "visibility,
reliability, and scalability". A primeira é a menos importante, a segunda é
bem interessante e a terceira, basicamente é que traz grandes benefícios
aos poucos. Quem são esses poucos? Facebook, Twitter, Google, Youtube,
Buscapé, Globo.com, mais umas centenas ou alguns poucos milhares de
serviços que concentram "todo mundo". Para eles a bolacha stateless faz a
diferença.

Os webservices que eu citei que eu desenvolvi, nenhum deles era REST
(stateless). Mas pensando bem, eu teria que rever a documentação de um
deles para ver se usávamos a sessão armazenada no servidor para alguma
coisa. Mas com certeza em nenhum caso usamos a semântica HTTP REST com
POST, PUT, etc. E sendo ou não REST, que nesse caso não eram, foram
webservices que atenderam completamente a necessidade.

> Em 29 de janeiro de 2015 18:49, Leonardo Ruoso <leonardo at ruoso.com>
>>> escreveu:
>>>
>>> Há um ponto que eu considero importante: nem todos os softwares precisam
>>>> ser web/rest. Muitos softwares podem usar HTTP para fazer RPC. Até aí
>>>> nenhum problema.
>>>>
>>>> O problema, a meu ver, é fazer uma coisa dizendo que está fazendo
>>>> outra, pelo fato de que a outra goza de melhor reputação. Isso é, para
>>>> começar, desonesto.
>>>>
>>>> Outro ponto que vale a pena considerar é que em tudo na vida a gente
>>>> precisa estabelecer os paradigmas sobre os quais vai trabalhar.
>>>>
>>>> Eu toparia participar de um workshop sobre RPC com Soap/WSDL sobre
>>>> HTTP/XMPP/SMTP, mas creio que ainda menos pessoas se interessariam por RPC
>>>> já que estudar Rest parece um investimento mais promissor hoje em dia.
>>>>
>>>> Pessoalmente eu estou bastante interessado em Rest, em compreender e
>>>> talvez em entender como modelar softwares em Rest. Em especial eu estou
>>>> interessado em gestão de autenticação e autorização para implementação de
>>>> SSO/ACL para o que eu entendo que é fundamental para ter um software Rest
>>>> que não seja equivalente à Wikipedia em termos de ACL.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Em 28 de janeiro de 2015 16:34, Kojo <rbsnkjmr at gmail.com> escreveu:
>>>>
>>>> Em 28 de janeiro de 2015 11:24, Renato Santos <renato.cron at gmail.com>
>>>>> escreveu:
>>>>>
>>>>>> O protocolo HTTP em si, é stateless, e trabalha em cima do TCP.
>>>>>>
>>>>>> O TCP sim é stateful, e existe todo um protocolo *complexo* (ACK,
>>>>>> Flags, *Sequence*, e window size) para que todo ele funcione.
>>>>>>
>>>>>> Como HTTP não tem estado, ou seja, a string "GET /meu-saldo\n\n" não
>>>>>> contém nenhuma informação sobre os estados anteriores.
>>>>>> Mesmo com headers (cookie) e query-parameters (api-key) o
>>>>>> HTTP-per-si, é stateless.
>>>>>>
>>>>>
>>>>>
>>>>> O HTTP é stateless mas a maiorida das aplicações que rodam sobre ele
>>>>> não, então implementam o mecanismo de sessão para manter o estado. O REST
>>>>> não, ele propõe transações atômicas para possibilitar a otimização de
>>>>> recursos, de acordo com o que vc descreve abaixo.
>>>>>
>>>>>
>>>>> O problema é acontece quando, como server, você precisar que algum
>>>>>> header ou query-parameter seja enviado para algum server em especial para
>>>>>> receber a resposta correta.
>>>>>>
>>>>>> Os dados do Request HTTP deveriam poder passar por todos os proxys e
>>>>>> servers sem sofrer alterações nas respostas [1].
>>>>>>
>>>>>> Quando a aplicação recebe o HTTP e lê ele, ela deveria sempre dar uma
>>>>>> resposta concisa sobre o que foi pedido, não importando do *estado a
>>>>>> aplicação. *Ela pode ser um servidor que acabou de ligar, pode ser
>>>>>> um que está rodando a horas, pode ser o ultimo request que o load-balance
>>>>>> está esperando terminar antes de desligar o servidor.
>>>>>>
>>>>>> A *visão *deste cookie/param tem que ser global entre os servidores.
>>>>>> caso contrario, precisa usar sticky session. E sticky session é o que é
>>>>>> horrível.
>>>>>>
>>>>>> Hoje, com memcached, redis, leveldb, é muito fácil ter essa visão
>>>>>> global dos estados de cada cliente.
>>>>>>
>>>>>
>>>>> Eu não entendo como esses mecanismos de cache impactam a arquitetura
>>>>> stateless do REST de maneira positiva. Sei que eles trazem ganhos de
>>>>> performance muito grande na leitura de dados, mas não que mude a
>>>>> arquitetura em sí. Vc pode dar algum exemplo?
>>>>>
>>>>>
>>>>>
>>>>> [1] exceção de proxys que tentam colocar cache, ad's e bloquear o
>>>>>> acesso, mas esse nao é o proxy que eu falo!
>>>>>> inclusive isso me lembra que, a maior parte de quem usa proxys de
>>>>>> cache, tipo o varnish, fazem algum IF para dropar o cache caso tenha alguma
>>>>>> indicação de 'stateful' no header/api-key.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-01-28 10:45 GMT-02:00 Kojo <rbsnkjmr at gmail.com>:
>>>>>>
>>>>>>
>>>>>>>>> O REST mantém o conceito de HTTP stateless, ou seja, o server
>>>>>>>>> nunca sabe quem é o cliente, então não tem nada guardado em memória, não
>>>>>>>>> tem nenhuma persistência de estado dos seus dados em relação aos seus
>>>>>>>>> clientes. Isso é uma grande vantagem, mas para poucos, porque o grande
>>>>>>>>> alívio que ele trás é para os serviços web que transacionam simultaneamente
>>>>>>>>> com milhṍes de clientes, poupando memória, processamento, e infra em geral
>>>>>>>>> para persistir os dados.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Não apenas, há várias outras vantagens em se trabalhar com
>>>>>>>> stateless.
>>>>>>>>
>>>>>>>
>>>>>>> As vantagens que eu vejo no stateless estão todas relacionadas com
>>>>>>> otimização de memória, não cache em cluster, não administração de sessão
>>>>>>> etc.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Para outros webservices, que transacionam com "poucos clientes"
>>>>>>>>> pode ser utilizada "qualquer arquitetura" que não fará muita diferença, vai
>>>>>>>>> custar pouco e os servidores vão aguentar do mesmo jeito. Qdo falo em qquer
>>>>>>>>> arquitetura, pode até ser um "REST stateful", que na verdade não é REST na
>>>>>>>>> acepção da palavra.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Qual seria um exemplo?
>>>>>>>>
>>>>>>>
>>>>>>> Por exemplo uma aplicação web stateful que ofereça todos os métodos
>>>>>>> que as partes necessitam em um webservice, como criação, update, leitura e
>>>>>>> deleção, sem se preocupar com a semântica dos métodos HTTP sem se preocupar
>>>>>>> em ser stateles. Em suma, uma aplicação web qquer que retorne xml, json ou
>>>>>>> qquer coisa inclusive documentos.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Em termos de penetração de mercado acho REST limitado, e pensando
>>>>>>>>> em um "REST stateful" acho que uma boa abordagem é o Websocket. O Websocket
>>>>>>>>> elimina um outro problema do HTTP que além de ser stateless, é o
>>>>>>>>> sincronismo. O HTTP é blocante e o cliente fica pendurado esperando a
>>>>>>>>> resposta, carregando o servidor web. Já o Websocket é assincrono e por isso
>>>>>>>>> aceita milhões de requisições que não ficam penduradas.
>>>>>>>>>
>>>>>>>>
>>>>>>>> WebSocket funciona em cima de HTTP :p
>>>>>>>>
>>>>>>>
>>>>>>> Funciona sobre HTTP mas não é uma premissa. O Websocket usa o HTTP
>>>>>>> para fazer handshake e aproveita toda a infra do HTTP como as portas 80 e
>>>>>>> 443, proxy etc, mas a idéia é futuramente mandar ele para outra porta e
>>>>>>> deixar o protocolo independente. Ele funciona como se fosse tunelado, ou
>>>>>>> seja, se vc estabelecer uma camada de transporte para ele, o resto já tá
>>>>>>> pronto. E a RFC diz que futuramente vai ser feito.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> WebSocket per-se provavelmente é uma má-ideia. Provavelmente AMQP
>>>>>>>> sobre WebSocket seja uma solução mais robusta.
>>>>>>>>
>>>>>>> E em muito tempo a única forma racional (efetiva, eficaz e
>>>>>>>> eficiente) que encontrei para implementar sistemas com WebSocket é baseada
>>>>>>>> em Schema/LD.
>>>>>>>>
>>>>>>>
>>>>>>> Faz sentido, pq o Websocket é um protocolo e REST é uma arquitetura.
>>>>>>> AMQP começa a ser uma composição de MQ com Websocket e tal. Aí começa a se
>>>>>>> montar uma arquitetura compondo várias tecnologias e protocolos.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Não estou dizendo que a arquitetura REST não é boa nem que não tem
>>>>>>>>> utilidade, mas que é para poucos. HATEOAS me soa a mesma coisa, eu nunca
>>>>>>>>> tinha ouvido falar, mas me lembrou WSDL, SOAP, etc.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Na verdade Rest é oposto a SOAP, que embora também suporte
>>>>>>>> documentos e não apenas RPC, não tem as premissas de funcionar em WEB.
>>>>>>>>
>>>>>>>> Mas, sim, para fazer RPC tunelado sobre HTTP, XMPP, SMTP eu diria
>>>>>>>> que ainda hoje o padrão mais maduro é, sem dúvida, SOAP/WSDL. Certamente é
>>>>>>>> o que torna o desenvolvimento de software mais fácil.
>>>>>>>>
>>>>>>>
>>>>>>> Eu já trabalhei em uma implementação de SOAP e WSDL em PERL. A
>>>>>>> empresa consumia os nossos webservices e foi uma solução interessante, a
>>>>>>> arquitetura era deles. Eu acho que a solução funcionava bem porque não eram
>>>>>>> muitos requests, senão valeria a pena pensar em algo assíncrono.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Em 26 de janeiro de 2015 21:08, Leonardo Ruoso <leonardo at ruoso.com
>>>>>>>>> > escreveu:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus <
>>>>>>>>>> lucasmateus.oliveira at gmail.com> escreveu:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Eu uso o Catalyst::Controller::REST que implementa todo o “sexo
>>>>>>>>>>> dos anjos” pra mim e vou ser feliz :D
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Não falta pretenção para o Catalyst::Controller::REST
>>>>>>>>>>
>>>>>>>>>> Quanto a ser feliz, bem, eu acredito que se conseguirmos
>>>>>>>>>> construir uma infraestrutura de software e uma prova de conceito Rest em
>>>>>>>>>> Perl, em cima do Catalyst, por exemplo, com View, Controller e Model
>>>>>>>>>> requerendo interfaces Rest de classes Moose (incluindo DBIx::Class
>>>>>>>>>> Result(set)), vamos ser mais que felizes.
>>>>>>>>>>
>>>>>>>>>> Se tiver uma galera na comunidade Perl entendo o que é Rest eu
>>>>>>>>>> já, pessoalmente, ficarei muito feliz demais da conta.
>>>>>>>>>>
>>>>>>>>>> Que a galera Java, por exemplo, já está acordando para a vida.
>>>>>>>>>>
>>>>>>>>>> Em 26/01/2015, à(s) 18:18, Leonardo Ruoso <leonardo at ruoso.com>
>>>>>>>>>>> escreveu:
>>>>>>>>>>>
>>>>>>>>>>> Em todo caso, mesmo que seja possível fazer (JSON|XML)-RPC bem
>>>>>>>>>>> feito, há um motivo pelo qual todo mundo quer Rest: *REST É O
>>>>>>>>>>> ÚLTIMO BISCOITO DO PACOTE*! JSON-RPC funciona, mas não é Rest e
>>>>>>>>>>> por isso não tem todas as vantagens sensacionais do Rest.
>>>>>>>>>>>
>>>>>>>>>>> Em 26 de janeiro de 2015 14:54, Renato Santos <
>>>>>>>>>>> renato.cron at gmail.com> escreveu:
>>>>>>>>>>>
>>>>>>>>>>>> Eu posso me juntar, mas já digo que eu só faço API's REST, não
>>>>>>>>>>>> RESTFul, e que nunca ouvi falar de HyperDocument e que linked-data pra mim
>>>>>>>>>>>> tem que ser em RDF!
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2015-01-26 14:51 GMT-02:00 Lucas Mateus <
>>>>>>>>>>>> lucasmateus.oliveira at gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Em 25/01/2015, à(s) 18:45, Leonardo Ruoso <leonardo at ruoso.com>
>>>>>>>>>>>>> escreveu:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Caso na comunidade tenha gente disposta a se atualizar sobre
>>>>>>>>>>>>> Restful (um conceito novo, lançado em 2000, e que se tornou a principal
>>>>>>>>>>>>> vedete do desenvolvimento de software contemporâneo) e disposta a parar de
>>>>>>>>>>>>> mentir para seus chefes e clientes de que está entregando restful quando
>>>>>>>>>>>>> está na verdade entregando um tipo de RPC mais-que-porco, eu teria um
>>>>>>>>>>>>> imenso prazer em integrar um grupo de estudo e de desenvolvimento com esse
>>>>>>>>>>>>> objetivo.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hahaha comunidade de mentirosos :D
>>>>>>>>>>>>>
>>>>>>>>>>>>> =begin disclaimer
>>>>>>>>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>>>>>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>>>>>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>>>>>>>>>>> =end disclaimer
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Saravá,
>>>>>>>>>>>> Renato CRON
>>>>>>>>>>>> http://www.renatocron.com/blog/
>>>>>>>>>>>> @renato_cron <http://twitter.com/#!/renato_cron>
>>>>>>>>>>>>
>>>>>>>>>>>> =begin disclaimer
>>>>>>>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>>>>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>>>>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>>>>>>>>>> =end disclaimer
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Leonardo Ruoso
>>>>>>>>>>> Journalist, Perl developer and business consultant
>>>>>>>>>>> Media, UFC/2006; Telecom, IFCE/1998
>>>>>>>>>>>  =begin disclaimer
>>>>>>>>>>>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>>>>>>>> SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>>>>>>>>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>>>>>>>>> =end disclaimer
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> =begin disclaimer
>>>>>>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>>>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>>>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>>>>>>>>> =end disclaimer
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Leonardo Ruoso
>>>>>>>>>> Journalist, Perl developer and business consultant
>>>>>>>>>> Media, UFC/2006; Telecom, IFCE/1998
>>>>>>>>>>
>>>>>>>>>> =begin disclaimer
>>>>>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>>>>>>>> =end disclaimer
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> =begin disclaimer
>>>>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>>>>>>> =end disclaimer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Leonardo Ruoso
>>>>>>>> Journalist, Perl developer and business consultant
>>>>>>>> Media, UFC/2006; Telecom, IFCE/1998
>>>>>>>>
>>>>>>>> =begin disclaimer
>>>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>>>>>> =end disclaimer
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> =begin disclaimer
>>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>>>>> =end disclaimer
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Saravá,
>>>>>> Renato CRON
>>>>>> http://www.renatocron.com/blog/
>>>>>> @renato_cron <http://twitter.com/#!/renato_cron>
>>>>>>
>>>>>> =begin disclaimer
>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>>>> =end disclaimer
>>>>>>
>>>>>>
>>>>>
>>>>> =begin disclaimer
>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>>> =end disclaimer
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Leonardo Ruoso
>>>> Journalist, Perl developer and business consultant
>>>> Media, UFC/2006; Telecom, IFCE/1998
>>>>
>>>> =begin disclaimer
>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>> =end disclaimer
>>>>
>>>>
>>>
>>
>> =begin disclaimer
>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>> =end disclaimer
>>
>>
>
>
> --
> "o animal satisfeito dorme". - Guimarães Rosa
>
> =begin disclaimer
>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150131/7b23edc1/attachment-0001.html>