Programação · web · API

gRPC vs REST

Quando desenha a comunicação entre dois programas numa rede, a bifurcação moderna é REST vs gRPC. Ambos expõem funcionalidades via HTTP, mas fazem apostas opostas: o REST privilegia a simplicidade legível e universal; o gRPC a eficiência rápida, tipada, binária. Este guia compara-os honestamente quanto a formato, desempenho, streaming, suporte de navegador e ferramentas – e quando escolher cada um. (Novo nas APIs? Comece por o que é uma API.)

A diferença fundamental

• REST – um estilo de arquitetura sobre HTTP: recursos em URL, verbos HTTP (GET/POST/PUT/DELETE), em geral JSON. Legível, sem estado, universal.
• gRPC – uma framework de chamadas de procedimento remoto: chama métodos (como funções locais) definidos num contrato .proto, trocando Protocol Buffers binários sobre HTTP/2.

O REST é orientado a recursos («vai buscar esta coisa»); o gRPC é orientado à ação («chama este método»). O REST é texto; o gRPC é binário e fortemente tipado.

Desempenho e transporte

Os Protocol Buffers do gRPC são binário compacto, enviado sobre ligações HTTP/2 multiplexadas – cargas mais pequenas, menos parsing, várias chamadas numa só ligação. O JSON do REST sobre HTTP/1.1 é mais pesado e verboso, ainda que muito otimizado e cacheável. Para o tráfego entre serviços de alto volume, a eficiência do gRPC é real; para uma API pública típica, o REST muitas vezes chega e aproveita a cache HTTP gratuita.

Streaming, contratos e codegen

O gRPC suporta nativamente o streaming bidirecional (cliente, servidor e nos dois sentidos), ideal para tempo real e alto débito. O seu ficheiro .proto é um contrato rigoroso a partir do qual clientes e servidores são gerados em muitas linguagens – perfeito para back-ends poliglotas e para detetar incompatibilidades em tempo de compilação. O REST não tem contrato integrado (o OpenAPI/Swagger é acrescentado) e o streaming é limitado (SSE/WebSockets acrescentados), mas essa flexibilidade é também o que torna fácil começar.

Suporte de navegador e ubiquidade

Este é o terreno do REST. Qualquer navegador chama uma API REST via fetch; cada linguagem e ferramenta a compreende; faz-se o debug com curl e lê-se o JSON. Os navegadores não falam gRPC puro – é preciso gRPC-Web mais um proxy (por ex. Envoy), o que acrescenta peças móveis. Se os seus front-ends web são os consumidores principais, o REST (ou GraphQL) é mais simples.

Como escolher

• Escolha REST para APIs públicas, clientes de navegador, CRUD simples e quando contam a legibilidade, a ubiquidade e a cache HTTP.
• Escolha gRPC para chamadas internas entre serviços onde contam o desempenho, a baixa latência, o streaming e o contrato rigorosamente tipado (microsserviços, tempo real, poliglota).
• Ambos – REST/GraphQL na fronteira para os clientes, gRPC entre os serviços internos: uma arquitetura muito difundida.

Perguntas frequentes

Qual é a diferença entre gRPC e REST?

O REST é um estilo de arquitetura para APIs web assente em HTTP, que troca normalmente JSON legível através de URL de recursos. O gRPC é uma framework RPC de alto desempenho que corre sobre HTTP/2 e troca Protocol Buffers binários, definidos por um contrato .proto rigoroso. Em resumo: o REST é orientado a recursos, textual e universal; o gRPC é orientado à ação (ao método), binário, tipado e rápido. Ambos resolvem o mesmo problema – programas que comunicam numa rede – com compromissos diferentes.

O gRPC é mais rápido do que o REST?

Em geral, sim para o tráfego entre serviços. O gRPC envia Protocol Buffers binários compactos sobre ligações HTTP/2 multiplexadas: cargas mais pequenas, menos sobrecarga do que JSON sobre HTTP/1.1 e streaming bidirecional. A diferença conta sobretudo para microsserviços internos de alto volume; para uma API pública pouco sobrecarregada, o REST + cache HTTP é muitas vezes mais do que suficiente.

É possível usar gRPC num navegador?

Não diretamente. Os navegadores não falam gRPC puro porque não expõem o controlo HTTP/2 de baixo nível de que o gRPC precisa. Usa-se gRPC-Web com um proxy (por ex. Envoy) como ponte, o que acrescenta complexidade e limita algumas funções (como o streaming do cliente). O REST, por seu lado, funciona nativamente a partir de qualquer navegador via fetch. Se a sua API é consumida sobretudo por front-ends web, o REST (ou GraphQL) é mais simples.

Quando usar gRPC em vez de REST?

Escolha gRPC para a comunicação interna entre serviços onde contam o desempenho, a baixa latência, o streaming e um contrato rigorosamente tipado – microsserviços, dados em tempo real, back-ends poliglotas. Escolha REST para APIs públicas, clientes de navegador, CRUD simples de recursos e quando contam a legibilidade, a ubiquidade e a cache HTTP gratuita. Muitos sistemas usam ambos: REST/GraphQL na fronteira para os clientes, gRPC entre os serviços internos.

Em resumo

O REST e o gRPC não são rivais, mas ferramentas para tarefas diferentes. O REST ganha na universalidade, no suporte de navegador, na legibilidade e na cache – a escolha certa por defeito para APIs públicas e web. O gRPC ganha na velocidade, no streaming e nos contratos tipados – a escolha certa por defeito para microsserviços internos de alto desempenho. Escolha consoante os seus chamadores e o seu tráfego, e não hesite em usar ambos.