[SP-pm] Resumo do Evento Técnico

[Leonardo Ruoso]

Em 31 de janeiro de 2015 17:48, Renato Santos <renato.cron em 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 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/20150131/1b8475de/attachment.html>