REST
vs gRPC

SEÇÃO 01

Antes da parte técnica

Quando dois sistemas precisam trocar informação, eles precisam combinar três coisas: como pedir, como responder e qual formato os dados vão seguir.

REST e gRPC resolvem esse mesmo problema, mas com prioridades diferentes. REST prioriza simplicidade, leitura humana e compatibilidade. gRPC prioriza contrato forte, mensagens menores e comunicação eficiente entre máquinas.

Cliente pergunta: "qual é o usuário 42?"
Servidor responde: "aqui estão os dados"

REST: resposta em texto/JSON, fácil de ler
gRPC: resposta em Protobuf, compacta e tipada

Por isso a pergunta certa não é "qual é melhor?". A pergunta certa é: essa conversa precisa ser fácil de abrir e entender, ou precisa ser muito padronizada e eficiente em volume?

SEÇÃO 02

REST na prática

REST normalmente usa HTTP com JSON. Você acessa uma URL, escolhe um método como GET, POST, PUT ou DELETE, e recebe uma resposta em texto.

GET /users/42
Accept: application/json

{
  "id": 42,
  "name": "Ana",
  "role": "admin"
}

A grande força do REST é a familiaridade. Dá para testar no navegador, no Postman, no curl, no frontend, em praticamente qualquer linguagem. Se a API é pública, se precisa ser consumida por parceiros, ou se o produto ainda está mudando muito, REST costuma ser a escolha mais pragmática.

SEÇÃO 03

gRPC na prática

gRPC usa HTTP/2 por baixo e Protocol Buffers como formato de dados. Antes de chamar a API, cliente e servidor combinam um contrato em um arquivo .proto.

service UserService {
  rpc GetUser (UserRequest) returns (UserReply);
}

message UserRequest {
  int32 id = 1;
}

message UserReply {
  int32 id = 1;
  string name = 2;
  string role = 3;
}

Esse contrato gera código para o cliente e para o servidor. Em vez de montar JSON manualmente, você chama um método como se fosse uma função local: client.getUser({ id: 42 }).

O custo é que fica menos casual. Não é tão natural abrir no navegador e "ver a resposta". Em troca, o sistema ganha mensagens menores, tipos mais claros e uma comunicação melhor para alto volume entre serviços.

SEÇÃO 04

A diferença real

A diferença não está só no nome. REST geralmente transporta JSON, que é texto legível. gRPC transporta Protobuf, que é binário e mais compacto. REST costuma funcionar sobre o modelo mental tradicional de requisição e resposta. gRPC aproveita melhor recursos do HTTP/2, como multiplexação e streaming.

Se você está construindo uma API para um app web, REST tende a encaixar melhor. Se você está conectando vários serviços internos que fazem muitas chamadas entre si, gRPC pode reduzir custo de transferência e melhorar o comportamento sob concorrência.

SEÇÃO 05

Quando REST ganha

REST ganha quando simplicidade operacional importa mais que eficiência bruta. Isso acontece em muitas APIs reais.

• API pública: outras pessoas e empresas precisam consumir sem aprender um ecossistema novo.
• Frontend web: o navegador conversa naturalmente com HTTP e JSON.
• Debug rápido: abrir uma URL, copiar um curl ou olhar uma resposta no log já resolve muita coisa.
• Produto mudando: quando o domínio ainda está instável, a flexibilidade do JSON ajuda.

App mobile
   ↓
REST API pública
   ↓
Backend do produto

Em outras palavras: se muita gente diferente precisa entender a conversa, REST é uma escolha muito forte.

SEÇÃO 06

Quando gRPC ganha

gRPC ganha quando os sistemas já fazem parte do mesmo ambiente e precisam conversar muito, com pouco desperdício e contrato claro.

• Microsserviços internos: serviços do mesmo produto chamando uns aos outros o tempo todo.
• Alto volume: muitas chamadas pequenas em sequência ou concorrência alta.
• Contrato forte: cliente e servidor precisam concordar exatamente sobre campos e tipos.
• Streaming: envio contínuo de dados, como eventos, telemetria, chat ou processamento incremental.

API Gateway
   ↓
gRPC
   ↓
User Service · Match Service · Payment Service

Aqui a conversa por rádio faz sentido: as equipes já combinaram o formato, cada mensagem vai direto ao ponto e o sistema aguenta melhor quando o volume aumenta.

SEÇÃO 07

Ideia central

REST não é "antigo" e gRPC não é "automaticamente melhor". Eles resolvem o mesmo tipo de problema com prioridades diferentes.

Precisa ser fácil de consumir e debugar?
→ REST

Precisa ser compacto, tipado e eficiente entre serviços?
→ gRPC

REST é ótimo para expor produto. gRPC é forte para costurar serviços por dentro. A diferença não é sobre moda; é sobre o tipo de conversa que o sistema precisa sustentar.