Em 31 de janeiro de 2015 17:48, Renato Santos <renato.c...@gmail.com> escreveu:
> Mais links para ler: > > REST APIs must be hypertext-driven > - http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven > (too strict) > > Creating an efficient REST API with HTTP > - http://mark-kirby.co.uk/2013/creating-a-true-rest-api/ (cool) > > > No começo desta thread eu não conhecia esse tal REST do Dr Fielding. > E tem outro? Quer dizer, o tal Fielding é uma das principais referencias não apenas em Rest, mas também em HTTP. > Foi legal conhecer, mas ainda não entendo porque o Leonardo diz que os > REST-likes não ajudam sistemas mobiles/SPA. > 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. 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. Nem todo mundo que conheço gostam de AngularJS, algumas, inclusive, tem um > forte ódio (quase como o Eden vs Mojolicious). > 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. É 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. > 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? > > A unica parte que não entendi até agora foi essa: > > - 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. *[Failure > here implies that identification is not separated from interaction.]* > > 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? > 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. 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 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. 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. 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. -- 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