[SP-pm] Resumo do Evento Técnico

Kojo rbsnkjmr at gmail.com
Wed Jan 28 04:45:35 PST 2015


>
>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150128/28ca3210/attachment-0001.html>


More information about the SaoPaulo-pm mailing list