[SP-pm] Resumo do Evento Técnico

Leonardo Ruoso leonardo at ruoso.com
Thu Jan 29 12:49:24 PST 2015


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 <http://twitter.com/#!/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 <http://twitter.com/#!/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
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150129/89feb79e/attachment-0001.html>


More information about the SaoPaulo-pm mailing list