gRPC vs REST: Qual estilo de API?
O gRPC é um RPC binário contract-first sobre HTTP/2 com geração de código; o REST é JSON orientado a recursos sobre HTTP, ubíquo e amigável a navegadores.
O gRPC usa Protocol Buffers e HTTP/2 para chamadas compactas, rápidas e fortemente tipadas com streaming e clientes gerados, ideal para microsserviços internos. O REST usa verbos HTTP e JSON, é universalmente suportado, fácil de depurar com curl e funciona nativamente em navegadores. O gRPC favorece performance e contratos tipados; o REST favorece alcance, simplicidade e compatibilidade com navegadores.
| gRPC | REST | |
|---|---|---|
| Payload | Protobuf (binário) | JSON (texto) |
| Transporte | HTTP/2 | HTTP/1.1+ |
| Contratos | Fortes (.proto) | OpenAPI (opcional) |
| Navegador | Precisa de gRPC-Web | Nativo |
| Melhor para | Microsserviços internos | APIs públicas/de navegador |
Caso de uso e performance
O gRPC se destaca em chamadas internas serviço-a-serviço que precisam de baixa latência, streaming e clientes tipados gerados entre linguagens. O REST se destaca em APIs públicas, clientes de navegador e qualquer coisa que se beneficie de payloads legíveis por humanos e tooling amplo. Equipes frequentemente expõem REST externamente e usam gRPC internamente.
Em CI
Pipelines de gRPC executam codegen com protoc/buf e verificam se o código gerado está atualizado. Pipelines de REST validam o OpenAPI e executam testes de contrato. Ambos rodam em runners gerenciados, onde runners mais rápidos encurtam as etapas de codegen e de teste de contrato.
O veredito
Chamadas internas de microsserviços fortemente tipadas e de alta performance: gRPC. APIs públicas, voltadas a navegadores e legíveis por humanos com o tooling mais amplo: REST. Uma arquitetura comum usa REST na borda e gRPC entre serviços internos.