Em 29 de janeiro de 2015 23:39, Solli Honorio <shono...@gmail.com> escreveu:
> Estou realmente precisando tomar umas brejas contigo, > Mas claro. Essa é a ideia. Provavelmente, não só bregas, mas talvez podemos começar um livro sobre Restful e Perl... > afinal não estou conseguindo entender porque você está supervalorizando > uma tecnologia de implementação complicada e com um enorme overhead na > apresentação dos dados, em relação a outra menos complicada. > Qual a tecnologia com implementação complicada e qual a menos complicada? Eu estou defendendo que Rest é a maior sacada em Engenharia de Software desde o RDBMS, provavelmente. É melhor que SOAP/WSDL pelo fato de que Rest é melhor que RPC para a grande maioria das aplicações, ao menos das aplicações Enterprise ou Públicas. > Talvez eu esteja muito desatualizado com as novidades da antiga SOAP, mas > estamos falando de tecnologia dos anos 2000. > Sim, estamos falando de tecnologia dos anos 2000, sempre, tanto SOAP quanto REST datam da virada do século. > O tempo que eu utilizei isto, era de uma complexidade infernal, e o WS > Security então era algo aparte de complexidade e infraestrutura. E mesmo > assim, ao final do projeto, estávamos utilizando a velha e ruim > autenticação baseado em usuário e senha para a aplicação (e tudo mundo > estava utilizando a mesma senha mesmo com uma tentativa de politica rígida > de segurança), e expondo de maneira medonha o kerberos da empresa na > infeliz idéia de ter um SSO (Single Sing-on). > Você culpa o Otto e o Beau de Rochas quando um adolescente dirigindo embriagado assassina uma dúzia de pessoas que estavam aguardando o ônibus numa parada? Se não, então você entende que não deve atribuir as aberrações implementadas por profissionais com treinamento insuficiente à arquitetura que eles dizem estar adotando, correto? > Sinceramente não sei qual é a limitação tão impactante do REST em utilizar > tecnologia de autenticação baseado no oauth (like), secret token e session > token. Com relação a ACL, vejo simplesmente como uma opção de implementação > no software, e cada um o faz da maneira que achar melhor. Veja o caso do > sistema operacional, cada um tem a tua ACL, com as vantagens e desvantagens > de cada uma. > Opa, mas eu nunca, jamais em toda vida disse que OAuth2 não seria um bom mecanismo de autenticação, mas SSO e OAuth2 provavelmente são muito mais ortogonais como tecnologia que concorrentes. E quanto a cada um ter uma ACL diferente, bem, eu vejo uma tendência imensa de convergência, embora reconheça que seja um processo transgeracional, ainda assim, quanto mais heterogêneo o ambiente, mais especificação formal e mais abstração você precisa e não menos. > 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 >> >> > > > -- > "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 > > -- 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