[SP-pm] Resumo do Evento Técnico

Kojo rbsnkjmr at gmail.com
Thu Jan 29 15:45:32 PST 2015 

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 <leonardo at 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 <rbsnkjmr at gmail.com> escreveu:
>
> Em 28 de janeiro de 2015 11:24, Renato Santos <renato.cron at 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 <rbsnkjmr at 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 <leonardo at ruoso.com>
>>>>>> escreveu:
>>>>>>
>>>>>>
>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus <
>>>>>>> lucasmateus.oliveira at 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 <leonardo at 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.cron at 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.oliveira at gmail.com>:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Em 25/01/2015, à(s) 18:45, Leonardo Ruoso <leonardo at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150129/2baedb0e/attachment-0001.html>

More information about the SaoPaulo-pm mailing list