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 q
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