<div dir="ltr"><div>O protocolo HTTP em si, é stateless, e trabalha em cima do TCP. <br></div><div><br></div><div>O TCP sim é stateful, e existe todo um protocolo <i>complexo</i> (ACK, Flags, <b>Sequence</b>, e window size) para que todo ele funcione.</div><div><br></div><div>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.</div><div>Mesmo com headers (cookie) e query-parameters (api-key) o HTTP-per-si, é stateless.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>Os dados do Request HTTP deveriam poder passar por todos os proxys e servers sem sofrer alterações nas respostas [1].</div><div><br></div><div>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 <b>estado a aplicação. </b>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. </div><div><br></div><div>A <b>visão </b>deste cookie/param tem que ser global entre os servidores. caso contrario, precisa usar sticky session. E sticky session é o que é horrível. </div><div><br></div><div>Hoje, com memcached, redis, leveldb, é muito fácil ter essa visão global dos estados de cada cliente.</div><div><br></div><div>[1] exceção de proxys que tentam colocar cache, ad's e bloquear o acesso, mas esse nao é o proxy que eu falo!</div><div>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.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-28 10:45 GMT-02:00 Kojo <span dir="ltr"><<a href="mailto:rbsnkjmr@gmail.com" target="_blank">rbsnkjmr@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br>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. </div></blockquote><div><br></div></span><div>Não apenas, há várias outras vantagens em se trabalhar com stateless.<br></div></div></div></div></blockquote><div><br></div></span><div>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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div></span><div>Qual seria um exemplo?<br></div></div></div></div></blockquote><div><br></div></span><div>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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div></span><div>WebSocket funciona em cima de HTTP :p<br></div></div></div></div></blockquote><div> </div></span><div>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. </div><span class=""><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>WebSocket per-se provavelmente é uma má-ideia. Provavelmente AMQP sobre WebSocket seja uma solução mais robusta.<br></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>E em muito tempo a única forma racional (efetiva, eficaz e eficiente) que encontrei para implementar sistemas com WebSocket é baseada em Schema/LD.<br></div></div></div></div></blockquote><div><br></div></span><div>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.<br></div><span class=""><div><br></div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>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. </div></div></blockquote><div><br></div></span><div>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.<br><br></div><div>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.<br></div></div></div></div></blockquote><div><br></div></span><div>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. </div><div><div class="h5"><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote">Em 26 de janeiro de 2015 21:08, Leonardo Ruoso <span dir="ltr"><<a href="mailto:leonardo@ruoso.com" target="_blank">leonardo@ruoso.com</a>></span> escreveu:<div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">Em 26 de janeiro de 2015 18:20, Lucas Mateus <span dir="ltr"><<a href="mailto:lucasmateus.oliveira@gmail.com" target="_blank">lucasmateus.oliveira@gmail.com</a>></span> escreveu:<span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><span style="white-space:pre-wrap">        </span>Eu uso o Catalyst::Controller::REST que implementa todo o “sexo dos anjos” pra mim e vou ser feliz :D</div></div></blockquote><div><br></div></span><div>Não falta pretenção para o Catalyst::Controller::REST<br></div><div><br></div><div>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.</div><div><br></div><div>Se tiver uma galera na comunidade Perl entendo o que é Rest eu já, pessoalmente, ficarei muito feliz demais da conta.</div><div> </div><div>Que a galera Java, por exemplo, já está acordando para a vida.</div><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Em 26/01/2015, à(s) 18:18, Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com" target="_blank">leonardo@ruoso.com</a>> escreveu:<br></div><div><div><div><br><blockquote type="cite"><div dir="ltr">Em todo caso, mesmo que seja possível fazer (JSON|XML)-RPC bem feito, há um motivo pelo qual todo mundo quer Rest: <b>REST É O ÚLTIMO BISCOITO DO PACOTE</b>! JSON-RPC funciona, mas não é Rest e por isso não tem todas as vantagens sensacionais do Rest. </div><div class="gmail_extra"><br><div class="gmail_quote">Em 26 de janeiro de 2015 14:54, Renato Santos <span dir="ltr"><<a href="mailto:renato.cron@gmail.com" target="_blank">renato.cron@gmail.com</a>></span> escreveu:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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!<div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-26 14:51 GMT-02:00 Lucas Mateus <span dir="ltr"><<a href="mailto:lucasmateus.oliveira@gmail.com" target="_blank">lucasmateus.oliveira@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><div style="word-wrap:break-word"><br><div><div>Em 25/01/2015, à(s) 18:45, Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com" target="_blank">leonardo@ruoso.com</a>> escreveu:</div><span><br><blockquote type="cite"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">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.</span></blockquote></span></div><br><div>Hahaha comunidade de mentirosos :D</div></div><br></span><span>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></span></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div><span style="color:rgb(51,51,51);font-size:x-small">Saravá,</span></div><div><span style="color:rgb(51,51,51);font-size:x-small">Renato CRON</span></div><div><div style="text-align:right"><font color="#333333" size="1"><a href="http://www.renatocron.com/blog/" target="_blank">http://www.renatocron.com/blog/</a></font></div></div><div style="text-align:right"><font color="#333333" size="1"><a href="http://twitter.com/#!/renato_cron" target="_blank">@renato_cron</a></font></div></div>
</font></span></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Leonardo Ruoso<div>Journalist, Perl developer and business consultant<br><div>Media, UFC/2006; Telecom, IFCE/1998</div></div></div>
</div>
=begin disclaimer<br>   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br> SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br> L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>=end disclaimer<br></blockquote></div></div></div><br></div><br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div></div></div><div><div><br><br clear="all"><div><br></div>-- <br><div>Leonardo Ruoso<div>Journalist, Perl developer and business consultant<br><div>Media, UFC/2006; Telecom, IFCE/1998</div></div></div>
</div></div></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div></div></div><br></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div></div></div><div><div><br><br clear="all"><br>-- <br><div>Leonardo Ruoso<div>Journalist, Perl developer and business consultant<br><div>Media, UFC/2006; Telecom, IFCE/1998</div></div></div>
</div></div></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div></div></div><br></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div><span style="color:rgb(51,51,51);font-size:x-small">Saravá,</span></div><div><span style="color:rgb(51,51,51);font-size:x-small">Renato CRON</span></div><div><div style="text-align:right"><font size="1" color="#333333"><a href="http://www.renatocron.com/blog/" target="_blank">http://www.renatocron.com/blog/</a></font></div></div><div style="text-align:right"><font size="1" color="#333333"><a href="http://twitter.com/#!/renato_cron" target="_blank">@renato_cron</a></font></div></div>
</div>