<div dir="ltr">Em 1 de fevereiro de 2015 13:42, Alceu Rodrigues de Freitas Junior <span dir="ltr"><<a href="mailto:glasswalk3r@yahoo.com.br" target="_blank">glasswalk3r@yahoo.com.br</a>></span> escreveu:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01-02-2015 10:57, Leonardo Ruoso wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></span></blockquote><div><br></div><div>[...]</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 5) E a performance? E o cache?</blockquote></span></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Opa, performance e cache estão no amalgama das vantagens do Rest.<br>
<br>
</blockquote>
<br></span>
Pelo que estou acompanhando dos posts sobre este tema, meus conhecimento sobre Rest se encontram distantes da especificação original. :-)<br></blockquote><div><br></div><div>O único detalhe é que eu não conheço nenhuma segunda versão de especificação. :p</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Conheço um pouco de SOAP e já sofri bastante ao tentar implementar algo usando o "Programming Web Services with Perl" já que na época (2008/2009) o SOAP::Lite*** já não servia para praticamente merda nenhuma (não sei como está hoje) comparado a ferramentas de desenvolvimento para web services disponíveis para .Net e Java.<br></blockquote><div><br></div><div>Olha, eu uso muito os módulos do Daniel (meu irmão) para Catalyst, que estendem outros componentes e são dessa época aí (2007/2008). Então pode ser uma questão de escolher os módulos corretos. </div><div><br></div><div>Inclusive temos suporte para a aberração que é a implementação da Microsoft. Que está muito longe de ser boa: é uma desgraça de fato, mas temos de suportar para conversar com API feitas por pessoas que implementam .Net e que tem preguiça de estudar especificação e fazem qualquer merda sem se preocupar com o que estão fazendo só pelo fato de que está funcionando (parecendo funcionar) para eles. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">No entanto, essa história de baixo acoplamento/forte acoplamento tem forte relação com desempenho.</blockquote><div><br></div><div>Qual desempenho? Runtime?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Sei que o foco aqui é ambiente web, mas fica difícil uma interface com outro sistema ser de baixo acoplamento (e portanto ter uma série de abstrações) ter um desempenho melhor do que algo como fazer uma chamada RPC (Sun RPC, Java RMI, etc) ou mesmo incorporar no seu código uma biblioteca de terceiros.<br></blockquote><div><br></div><div>Um exemplo de clients que são ou deveriam ser desenvolvidos com baixo acoplamento e que tem performance excelente são os clientes de AMQP. No caso desses clientes as classes são construídas a partir dos elementos do XML da especificação do componente, logo se você estender o seu servidor (com plugins por exemplo) e usar apenas tipos previamente conhecidos o cliente deve ser capaz de conversar com seu plugin, ou seja, o que baixo acoplamento define é que se eu estiver usando a mesma versão da API eu posso ter objetos diferentes: eu tenho de saber lidar com todo o vocabulário da API, mas a API pode ser incrementada, decrementada ou modificada dentro do escopo desse vocabulário e seu cliente continuará compatível. O único impacto que eu percebo nisso é de compile time ou no momento em que recebo uma notificação de alteração do schema.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A especificação do SOAP é complexa porque em teoria deveria permitir que sistemas fizessem integrações entre si com o menor esforço possível... mas alguém aí já viu UDDI funcionando?<br></blockquote><div><br></div><div>Para SOAP/WSDL sobre HTTP, sobre XMPP e sobre SMTP.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Por outro lado eu já vi erros de integração usando SOAP que poderiam ter sido resolvidos em fase de projeto se simplesmente o XML Schema definido no WSDL tivesse incluído o tamanho máximo dos elementos (o que me faz pensar que a equipe de projeto estava tentando usar espoletas em uma Magnum 44).<br></blockquote><div><br></div><div>Mas você pode atualizar o WSDL em tempo de desenvolvimento caso identifique problemas no projeto original. </div><div><br></div><div>Isso são problemas ortogonais: waterfall vs agile não tem nada a ver com schema vs schema-less. Claro que fazer waterfall com schema-less é suicídio. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Estabelecidas minhas limitações sobre o tema... como o Rest se propõe a lidar com essas questões? Garantir que o formato de dados trocados seja interpretado da forma correta, com baixo acoplamento entre os dois sistemas e com desempenho vantajoso?<br></blockquote><div><br></div><div>Em XML as soluções são uma continuidade das soluções que estavam disponíveis no SOAP. Sendo conservadores, deveríamos usar XML até que as especificações JSON fossem aprovadas ou estivessem em vias de aprovação.</div><div><br></div><div>Para JSON temos Recommendation saindo, mas o normal é usar Json-Schema, Json-LD e suprir lacunas ainda existentes por imitação das opções disponíveis em HTML/XML.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Aliás, por desempenho vantajoso, estamos comparando o Rest com SOAP? XML RPC? JSON RPC?<br></blockquote><div><br></div><div>Questão de desempenho tende a ser bastante melhor com Rest uma vez que Rest permite usar Cache enquanto Soap não. Não faz sentido falar que um resultado de uma chamada síncrona não foi alterado desde hh:mm, enquanto faz todo sentido falar que um objeto persistido, um hyperdocumento, foi alterado pela última vez em hh:mm e por isso o cliente que já tem essa cópia pode não fazer um novo GET.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Abraço,<br>
<br>
Alceu<br>
<br>
*** já que estamos falando de livro sobre o tema, a literatura disponível para Perl e web services está completamente defasada, não?<div class="HOEnZb"><div class="h5"><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/<u></u>listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <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>