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:
- 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.
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:
- esqueça HTTP com microsserviços;
- Os dados não estão mais em REST;
- REST é o novo SOAP;
- é REST a melhor escolha em uma arquitetura de microsserviços?; e
- como REST síncrono transforma microsserviços de volta em monólitos.
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.