> > >> 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 <[email protected]> >> escreveu: >> >> >>> Em 26 de janeiro de 2015 18:20, Lucas Mateus < >>> [email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 < >>>>> [email protected]>: >>>>> >>>>>> >>>>>> Em 25/01/2015, à(s) 18:45, Leonardo Ruoso <[email protected]> >>>>>> 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: [email protected] >>>>>> 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: [email protected] >>>>> 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: [email protected] >>>> 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: [email protected] >>>> 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: [email protected] >>> 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: [email protected] >> 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: [email protected] > 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: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
