[SP-pm] Resumo do Evento Técnico

[Leonardo Ruoso]

Em 1 de fevereiro de 2015 13:42, Alceu Rodrigues de Freitas Junior <
glasswalk3r em yahoo.com.br> escreveu:

> On 01-02-2015 10:57, Leonardo Ruoso wrote:
>>
>>
[...]


>  5) E a performance? E o cache?
>
>
>>
>> Opa, performance e cache estão no amalgama das vantagens do Rest.
>>
>>
> Pelo que estou acompanhando dos posts sobre este tema, meus conhecimento
> sobre Rest se encontram distantes da especificação original. :-)
>

O único detalhe é que eu não conheço nenhuma segunda versão de
especificação. :p


> 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.
>

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.

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.


> No entanto, essa história de baixo acoplamento/forte acoplamento tem forte
> relação com desempenho.


Qual desempenho? Runtime?


> 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.
>

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.


> 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?
>

Para SOAP/WSDL sobre HTTP, sobre XMPP e sobre SMTP.


> 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).
>

Mas você pode atualizar o WSDL em tempo de desenvolvimento caso identifique
problemas no projeto original.

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.


> 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?
>

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.

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.


> Aliás, por desempenho vantajoso, estamos comparando o Rest com SOAP? XML
> RPC? JSON RPC?
>

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.


> Abraço,
>
> Alceu
>
> *** já que estamos falando de livro sobre o tema, a literatura disponível
> para Perl e web services está completamente defasada, não?
>
> =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/20150201/3bdd2199/attachment-0003.html>