JSON e XML são ortogonais a RPC e REST. Em 29 de janeiro de 2015 21:54, Kojo <rbsnk...@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. > > > > > > >> Em 29 de janeiro de 2015 18:49, Leonardo Ruoso <leona...@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 <rbsnk...@gmail.com> escreveu: >>> >>> Em 28 de janeiro de 2015 11:24, Renato Santos <renato.c...@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 <rbsnk...@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 <leona...@ruoso.com> >>>>>>>> escreveu: >>>>>>>> >>>>>>>> >>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus < >>>>>>>>> lucasmateus.olive...@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 <leona...@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.c...@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.olive...@gmail.com>: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Em 25/01/2015, à(s) 18:45, Leonardo Ruoso <leona...@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@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@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@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@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@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@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@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@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@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@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@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@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@pm.org L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer