Por Que (De Novo) REST Baseado em HTTP?

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

OUTRA VEZ HTTP?

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.

Experimenta

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:

  • HTTP, com a biblioteca express;
  • SOAP, com a biblioteca soap;
  • AMQP, com a biblioteca amqp;
  • MQTT, com a biblioteca mqtt; e
  • KAFKA, com a biblioteca kafka.
96, 1 ano antes da morte da Lady Diana. Coincidência? Eu acho que não.

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:

  • HTTP é simples e familiar;
  • Suporta comunicação request/response diretamente;
  • Grande quantidade de bibliotecas disponíveis;
  • Não requer um sistema mediador como brokers, o que simplifica a arquitetura do sistema; e
  • Inúmeras ferramentas para testar a API, como: curl, browsers comuns, postman etc..

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:

  • Oferece suporte somente ao estilo request/response de interação;
  • Não há intermediário para armazenar as mensagens. Logo, cliente e servidor devem estar em execução durante a troca de mensagens;
  • O cliente deve conhecer o endereço de cada instância do serviço, o que não é um problema trivial em aplicações modernas. Mecanismos de service discovery devem ser adotados para localizar tais instâncias;
  • A natureza síncrona imprime um forte acoplamento entre o cliente e o servidor;
  • Dificuldade da decomposição do servidor em diversos componentes, se necessário;
  • Exige a combinação de múltiplas requisições HTTP para a composição de informações complexas;
  • URL confusas para filtrar campos por meio de query parameters;
  • Overfetching, desperdício provocado quando dados além do necessário são enviados na mensagem;
  • A eterna confusão entre o PATCH e o PUT;
  • HTTP não foi feito para isso. O que não é um problema em si, mas vira um problema quando temos que nos expressar nos limitando apenas aos verbos HTTP (GET, POST, PATCH, PUT, DELETE etc.) e os códigos de status (200, 404, 500 etc.). Qual verbo você usaria para fazer uma validação de um payload?; e
  • Por último, mas não menos importante: adotar as boas práticas RESTful para criação de endpoints é o ó do borogodó.

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:

<trocadilho>Dê um descanso ao REST</trocadilho>

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.


Guilherme Virgs Moraes

Written by

I am a doer. Enthusiastic about everything, amazed at the life itself and the desire to evolve everyone's skills. https://pagehub.me/virgs

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade