<div dir="ltr">Em 31 de janeiro de 2015 17:48, Renato Santos <span dir="ltr"><<a href="mailto:renato.cron@gmail.com" target="_blank">renato.cron@gmail.com</a>></span> escreveu:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Mais links para ler:<div><br></div><div>REST APIs must be hypertext-driven<br><div> - <a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven" target="_blank">http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven</a> (too strict)<br></div><div><br></div><div>Creating an efficient REST API with HTTP<br></div><div> - <a href="http://mark-kirby.co.uk/2013/creating-a-true-rest-api/" target="_blank">http://mark-kirby.co.uk/2013/creating-a-true-rest-api/</a> (cool)<br></div><div><br></div><div><br></div><div>No começo desta thread eu não conhecia esse tal REST do Dr Fielding. </div></div></div></blockquote><div><br>E tem outro? Quer dizer, o tal Fielding é uma das principais referencias não apenas em Rest, mas também em HTTP.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Foi legal conhecer, mas ainda não entendo porque o Leonardo diz que os REST-likes não ajudam sistemas mobiles/SPA. </div></div></div></blockquote><div><br></div><div>Esse é um ponto que merece elaboração, mas o primeiro ponto seria a longevidade dos clientes, algo que é muito importante para IoT, Mobile e SPA. <br><br></div><div>O problema está em dizer que qualquer coisa que usa JSON/XML é Rest ou Rest-Like. Tudo que for Rest-Like ajuda em alguma proporção, mas desenvolvimento de aplicações com forte acoplamento entre Interface e API é tudo menos Rest-LIke e é aí que o caldo entorna.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Nem todo mundo que conheço gostam de AngularJS, algumas, inclusive, tem um forte ódio (quase como o Eden vs Mojolicious). </div></div></div></blockquote><div><br></div><div>Há algumas alternativas ao AngularJS. Pessoalmente eu conheço o AngularJS. Agora, AngularJS está muito mais para Catalyst que para Mojolicious. A tendência seria de que o Eden gostasse do AngularJS. De fato, não conheci ninguém que eu respeite como designer de software que não respeite considerável o AngularJS.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>É claro que uma SPA ficaria mais fácil de dar manutenção se as respostas à recursos da API contenham as URI's para os próximos recursos, mas não impossibilita a SPA de existir de uma forma regular.</div></div></div></blockquote><div><br></div><div>Um ponto que cabe entender para a discussão: Você entende o motivo de fraco acoplamento entre componentes de software, em especial componentes de rede, ser um aspecto importante para o desenvolvimento de boas API? Do contrário não vai adiantar eu dizer que o conceito de não haver informação específica da aplicação disponibilizada out-of-band é FUNDAMENTAL pelo fato de que esse princípio GARANTE o fraco acoplamento entre cliente e servidor. Correto?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div><div>A unica parte que não entendi até agora foi essa:</div><div><ul style="margin:1em;padding:0px;color:rgb(0,0,0);font-family:Georgia,Verdana,Arial,serif;font-size:medium"><li style="padding:0.5em">A REST API should not be dependent on any single communication protocol, though its successful mapping to a given protocol may be dependent on the availability of metadata, choice of methods, etc. In general, any protocol element that uses a URI for identification must allow any URI scheme to be used for the sake of that identification. <i>[Failure here implies that identification is not separated from interaction.]</i></li></ul></div><div>Como fazer uma API comunicável por diversos protocolos? HTTP e HTTPS não bastam? Os outros protocolos não podem ser "tunelados" por HTTP?</div></div></div></blockquote><div><br></div><div>Não, decididamente HTTP sobre SSL ou não são menos que bastante para todos os cenários. Eu diria que a existência de vários outros mecanismos de transporte como XMPP, AMQP, RMI, SMTP e outros usados para comunicação entre componentes de software já demonstra empíricamente essa necessidade, mesmo sem entrarmos nas especificidades do HTTP.<br></div><div class="gmail_extra"> <br></div><div class="gmail_extra">Mas, enfim, se sairmos com um entendimento melhor do que é Rest já lucramos com a conversa… Penso eu. Se três pessoas da lista se derem ao trabalho ao menos de ler a dissertação que conceitua o Rest e ½ dúzia de artigos, já teríamos realizado um grande avanço como comunidade e reduzido a quantidade de besteiras que falamos por aí :p<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Por outro lado, o que eu tenho experimentado com o fracasso dos projetos em implementar Rest, mesmo quando Rest é formalmente requisitado pelo contratante, tem ao menos uma grande consequência negativa, derivada diretamente do forte acoplamento entre interface (SPA, Mobile e IoT) e API: custo de manutenção elevada. Isso sem mencionar maior custo de atualização, menor escalabilidade e várias outras consequências bem conhecidas dos modelos de RPC amplamente adotados.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Precisamos, como desenvolvedores, entender o motivo pelo qual os GURUS da engenharia de software reconheceram no Rest o grande paradígma para resolver problemas bastante conhecidos dos desenvolvedores e esses problemas estão em grande parte associados justamente a sistemas que dependem de chamadas RPC para funcionar.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Se chegarmos a montar nosso grupo de estudo eu realmente gostaria de chegar num ponte de termos ao menos um software com uma API de referência funcionando simultaneamente em cima de HTTP(S) e AMQP (incluindo AMQP tunelado em WebSocket). Suportando HTML, JSON e XML, mesmo que seja uma aplicação bem simples como uma nova versão do ACT.<br><br><br><br><br></div><div class="gmail_extra">-- <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>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span class=""></span></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"><br>-- <br><div class="gmail_signature">Leonardo Ruoso<div>Journalist, Perl developer and business consultant<br><div>Media, UFC/2006; Telecom, IFCE/1998</div></div></div>
</div></div>