[SP-pm] Resumo do Evento Técnico

Leonardo Ruoso leonardo at ruoso.com
Fri Jan 30 13:02:15 PST 2015


Em 29 de janeiro de 2015 23:39, Solli Honorio <shonorio em 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 <leonardo em 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 em gmail.com> escreveu:
>>
>> Em 28 de janeiro de 2015 11:24, Renato Santos <renato.cron em 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 em 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 em ruoso.com>
>>>>>>> escreveu:
>>>>>>>
>>>>>>>
>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus <
>>>>>>>> lucasmateus.oliveira em 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 em 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 em 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 em gmail.com>:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Em 25/01/2015, à(s) 18:45, Leonardo Ruoso <leonardo em 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 em 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 em 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 em 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 em 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 em 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 em 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 em 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 em 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 em 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 em 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 em 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 em 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
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150130/8940580c/attachment-0001.html>


More information about the SaoPaulo-pm mailing list