[SP-pm] Resumo do Evento Técnico

Thu Jan 29 19:16:32 PST 2015

Nah...

A questão é que o termo REST, cunhado pelo tio Fielding
(http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm), é bem
específico.

Tecnicamente o que a gente chama de webservice REST com json pra lá e
json pra ca não bate com a definição específica de REST criada por
ele.

O próprio Fielding "dá piti" quando a gente chama nossos webservices
de RESTful, porque não bate com o termo que ele criou.

O que o Leo tá dizendo é que conceitualmente existem diferenças, e a
maioria esmagadora das pessoas, não entendem isso, gerando coisas
bizarras, como um webservice que se comporta como SOAP, mas porque faz
PUT e DELETE "quer ser REST".

No fim boa parte dessa conversa é só pra dizer se eu vou chamar o
treco de bolacha ou de biscoito.

[]'s

2015-01-29 23:58 GMT-02:00 Solli Honorio <shonorio em gmail.com>:
>
>
> Em 29 de janeiro de 2015 21:54, Kojo <rbsnkjmr em gmail.com> escreveu:
>>
>> Dedo gordo, continuando.
>>
>> Olha, realmente eu não tenho interesse em rever a documentação de SOAP e
>> WSDL mas estou achando essas discussão interessante porque nos obriga a
>> tratar dos diferentes padrões com rigor técnico.
>> Não sei se vale uma palestra, mas posso contar sobre as implementações de
>> webservice que já participei, uma delas transionando em XML, outra SOAP e
>> outra JSON.
>> A JSON foi bem simplesinha, a SOAP nem tanto porque trabalhar no protocolo
>> é exaustivo, e a XML foi uma solução caseira em 2001 bem interessante. Eu
>> teria que rever alguns documentos da época para clarear a memória, era uma
>> coleção de interfaces em XML para diferentes tipos de dados.
>>
>> Continuo achando que REST é para poucos porque dá para implementar um
>> webservice de várias maneiras, mas podendo participar da discussão estou
>> dentro.
>
>
>
> 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.
>
> O Leonardo fez um resumo que achei interessante, REST é WEB para aplicação,
> e é aí que vejo o poder deste cara. É tão simples que chega a ser
> complicado, e muito leve. É muito escalável e permitir implementar a
> tecnologia de autenticação mais adequado a tua necessidade. É muito simples
> implementar autenticação baseado em usuário/senha (inclusive com kerberos)
> via um sistema de proxy/web servicer, ou um ouath like.
>
> O REST é o paraíso em linguagens dinâmicas, credito até que a adoção em
> massa na internet só ocorreu por causa do grande número de projetos
> utilizando linguagens dinâmicas (Ruby, Python, Perl) em detrimento de Java e
> .Net (que alias é um pesadelo em utilizar o REST, mas parece que o Java está
> melhorando este quesito segundo o Leonardo).
>
>
>
>>
>>
>>
>>
>>
>>
>>>
>>> Em 29 de janeiro de 2015 18:49, Leonardo Ruoso <leonardo em 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 em gmail.com> escreveu:
>>>>
>>>>> Em 28 de janeiro de 2015 11:24, Renato Santos <renato.cron em 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 em 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 em ruoso.com>
>>>>>>>>> escreveu:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus
>>>>>>>>>> <lucasmateus.oliveira em 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 em 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 em 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 em gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Em 25/01/2015, à(s) 18:45, Leonardo Ruoso <leonardo em 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 em pm.org
>>>>>>>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>>>>>>>>>>> =end disclaimer
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Saravá,
>>>>>>>>>>>> Renato CRON
>>>>>>>>>>>> http://www.renatocron.com/blog/
>>>>>>>>>>>> @renato_cron
>>>>>>>>>>>>
>>>>>>>>>>>> =begin disclaimer
>>>>>>>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>>>>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm em 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 em 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 em 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 em 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 em 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 em 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 em pm.org
>>>>>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>>>>>> =end disclaimer
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Saravá,
>>>>>> Renato CRON
>>>>>> http://www.renatocron.com/blog/
>>>>>> @renato_cron
>>>>>>
>>>>>> =begin disclaimer
>>>>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>>>>  SaoPaulo-pm mailing list: SaoPaulo-pm em 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 em 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 em 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 em 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 em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>