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 <shono...@gmail.com>: > > > 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. > > > > 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 <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 >>>>>>>>>>>> >>>>>>>>>>>> =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 >>>>>> >>>>>> =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 >> > > > > -- > "o animal satisfeito dorme". - Guimarães Rosa > > =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