Por Que (De Novo) REST Baseado em HTTP? cover

Por Que (De Novo) REST Baseado em HTTP?

O protocolo REST/HTTP é a solução universal para a troca de mensagens?

24/Jul/2018
5 minutos

Não!

Categoricamente: não é a solução universal! Hoje em dia, há um sentimento que microservices exigem APIs RESTful/HTTP. Contudo, muitos aspectos devem ser levados em consideração antes de se escolher o protocolo de comunicação entre serviços. Inclusive, nada impede que mais de um protocolo seja utilizado em um mesmo fluxo.

APIs HTTP estão na moda

Talvez o protocolo mais usado nos dias atuais. Independentemente do problema e do contexto, percebe-se uma API RESTful, com endpoints HTTP e JSONs sendo enviados para cima e para baixo, sendo escolhida como o paradigma de troca de mensagens padrão em uma arquitetura de microsserviços. Talvez se dê por sua facilidade ou pela infinidade de bibliotecas disponíveis no mercado. Mas o questionamento que pretende ser levantado é o porquê HTTP ser, aparentemente, a única escolha.

Vejam o que fala Martin Fowler sobre microservices:

“…cada um executando em seu próprio processo e se comunicando com mecanismos leves, frequentemente uma API com recursos HTTP……”

O que é dito é que a comunicação ocorre por mecanismos “leves”, frequentemente HTTP. Percebam que em momento algum há exigências quanto a escolha.

Dando número aos bois

Por meio de uma brevíssima pesquisa nos pacotes disponíveis no repositório npm, foram levantados os protocolos mais utilizados, suas respectivas bibliotecas mais populares e a quantidade de downloads feitos na última semana. Sabe-se que npm não é a melhor fonte de verdade, e reforça-se o que a pesquisa foi realmente BEM breve, mas é suficiente para ilustrar o que aqui é desejado_._ Os protocolos, e suas respectivas bibliotecas, pesquisados foram:

O resultado não é de todo surpreendente. Enquanto mais de 4 milhões de downloads foram feitos da biblioteca express, apenas pouco mais de 50 mil foram feitos da biblioteca amqp, a segunda biblioteca mais utilizada. A diferença é gritante e chama muita atenção. Os outros números não serão mencionados porque a planilha que foi utilizada para gerar esse gráfico foi perdida. :)

A questão é: em 96% dos contextos, é REST/HTTP a solução mais adequada?

Salienta-se que, ao usar o protocolo REST baseado em HTTP, muitos benefícios são encontrados:

Todavia, os benefícios não são suficientes para se assumir REST/HTTP a opção padrão. Existem também excelentes argumentos contra:

Ainda não está convencido? Além dos contra-argumentos supracitados, abaixo há uma lista de outros artigos que estimulam uma reflexão prévia e a cogitação de outros mecanismos de trocas de mensagens ao invés da adoção imediata de REST/HTTP:

Conclusão

De modo geral, HTTP e protocolos síncronos, como um grupo, são desencorajados por promover o acoplamento entre os microservices, fragilizando a autonomia individual e, consequentemente, a resiliência de toda a solução. Exatamente o contrário do que pregam os sistemas reativos.

Como visto nos pontos elencados acima, o paradigma REST/HTTP como mecanismo de troca de mensagens traz consigo muitas desvantagens e, por conta disso, não pode ser assumido como bala de prata e ser utilizado para resolver todos os problemas.

Não que REST/HTTP nunca deve ser usado. É provável, inclusive, que seja o mais adequado em muitos casos. Entretanto, a escolha do protocolo IPC envolve muitas outras variáveis e não pode ser negligenciada.

O que se defende é que se faça um levantamento mais minucioso do problema em questão antes de escolher o protocolo mais apropriado.

Este texto serviu de base para um capítulo do meu livro. Se você gostou do texto, considere adquirir o livro.

Já que você tá por aqui, dá uma olhada nesses aqui também: