Entendendo gRPC, OpenAPI e REST e quando usá-los no design de APIs (2020)

Gerenciamento de APIs

gRPC e REST: entendendo gRPC, OpenAPI e REST no design de APIs e quando usar cada um

• Modelos de design de API: no design de APIs, são usados principalmente dois modelos: RPC e REST. A maioria das APIs modernas é implementada com base no protocolo HTTP.
• gRPC: tecnologia de implementação de APIs RPC que usa HTTP 2.0 como protocolo de transporte. Google e outras empresas usam bastante APIs que combinam as ideias de RPC e HTTP.
• Três principais formas de usar HTTP:
  1. REST: o cliente usa diretamente as URLs fornecidas pelo servidor, sem precisar entender o formato da URL.
  2. gRPC: usa HTTP/2, mas o HTTP não fica exposto ao projetista da API.
  3. OpenAPI: o cliente chama a API usando templates de caminho de URL.

REST

• Características: o cliente não precisa entender o formato da URL, e a URL não faz parte da especificação da API.
• Vantagens: oferece os benefícios da web, como estabilidade, consistência e universalidade. O modelo orientado a entidades é mais simples e fácil de entender.

gRPC

• Características: usa HTTP/2, mas os detalhes de HTTP ficam ocultos. O cliente usa a API chamando procedimentos e passando parâmetros.
• Vantagens: é fácil gerar bibliotecas de programação no lado do cliente, e o desempenho é bom.

OpenAPI

• Características: chama a API usando templates de caminho de URL, e o cliente precisa entender o formato da URL.
• Vantagens: é possível acessar a API apenas com tecnologias HTTP padrão. Também é possível gerar bibliotecas de programação no lado do cliente.

Comparação entre gRPC e OpenAPI

• Semelhanças: ambos podem ser usados como linguagem de definição de interface RPC (IDL).
• Diferenças: o gRPC oculta os detalhes de HTTP, enquanto o OpenAPI os expõe.

Vantagens do REST

• Modelo orientado a entidades: é mais simples, mais fácil de entender e permanece estável ao longo do tempo.

Como usar OpenAPI

• Definição de caminhos: a API é definida usando caminhos e métodos HTTP.

Vantagens e desvantagens do OpenAPI

• Vantagens: é semelhante ao modelo RPC, sendo familiar para programadores. Pode ser mapeado para requisições HTTP.
• Desvantagens: exige muito esforço para projetar os detalhes de HTTP.

Vantagens do gRPC

• Implementação simples: a implementação no lado do servidor é simples, e é fácil gerar bibliotecas no lado do cliente.
• Desempenho: é eficiente por usar payloads binários.

Desvantagens do gRPC

• Necessidade de software específico: tanto o cliente quanto o servidor precisam de software específico.
• Limitações em proxies: diferentemente de APIs HTTP, é difícil expandir ou modificar funcionalidades em proxies.

Conclusão

• Escolha do design de API: é preciso escolher considerando as vantagens e desvantagens de REST, OpenAPI e gRPC.
• Pontos a considerar ao usar gRPC: ele é vantajoso em APIs internas, quando os clientes não precisam adotar a tecnologia gRPC.

[GN⁺]

Opiniões do Hacker News

• Há arrependimento por ter aprendido gRPC. Muito tempo foi gasto com depuração e ajuste de configuração

  • Dizem que o gRPC esconde os detalhes internos, mas, na prática, exigiu muita depuração e ajuste de configuração
  • Muito tempo foi desperdiçado com plugin do Maven, problemas de compatibilidade com HTTP2 e problemas de firewall
  • A documentação era fraca, e houve dificuldade para tornar as mensagens de erro observáveis

• A pessoa vem construindo APIs há muito tempo e já usou gRPC e HTTP/REST

  • Acha estranho separar OpenAPI e REST como se fossem coisas diferentes
  • OpenAPI é uma forma de documentar o comportamento de uma API HTTP e pode representar uma API RESTful
  • gRPC é um mecanismo de RPC que troca Protocol Buffers
  • gRPC é eficiente, mas não é tão poderoso quanto bibliotecas HTTP

• Há experiência de trabalho em FAANG, e a pessoa considera o gRPC útil para roteamento interno de serviços

  • Protocolos RPC permitem operar em grande escala e alta velocidade
  • Porém, não usaria gRPC para clientes ou para a web

• A menos que haja streaming bidirecional, gRPC parece uma perda de tempo

  • É preciso muito middleware para fazer chamadas RPC entre serviços implementados em várias linguagens

• Em um projeto que adotou gRPC por desempenho, acabou havendo migração para uma API JSON

  • Faltava experiência com gRPC, e o projeto fracassou por vários problemas

• Ao usar connectrpc, os problemas do gRPC estão sendo resolvidos

  • Com buf.build, é fácil importar arquivos proto de terceiros
  • O recurso de geração automática de SDK é muito útil

• gRPC parece oferecer uma experiência de desenvolvimento pior do que REST

  • Ferramentas adicionais são necessárias, e o código de cliente gerado é complexo

• Roy Fielding mencionou que, em uma API REST, basta conhecer o URI inicial e os tipos de mídia padronizados

• Não há preferência pelo uso de gRPC dentro do data center

  • O desempenho não é tão alto, e a qualidade dos clientes open source é baixa
  • Em APIs baseadas na web, prefere-se a legibilidade do JSON, embora haja problemas de incompatibilidade de tipos

• Houve a sensação de que o gRPC é difícil de abordar fora do Google

  • O cliente gRPC JS é pesado e opaco
  • Em comparação com a simplicidade do REST, parece uma execução equivocada