REST, GraphQL e gRPC: modelos de comunicação

Os três resolvem o mesmo problema — cliente e servidor trocando dado estruturado pela rede — mas cada um parte de uma filosofia diferente sobre o que deve ser fácil e o que pode ser mais trabalhoso.

REST — o recurso é a unidade central

Numa API REST, cada URL identifica um recurso (/usuarios/42, /usuarios/42/pedidos), e o método HTTP diz a operação (GET busca, POST cria). O formato da resposta é fixo, decidido pelo servidor — o que é simples de cachear (URLs batem naturalmente com cache de CDN e navegador), mas pode obrigar o cliente a fazer várias requisições pra montar uma tela, ou receber campos que nem vai usar.

GET /usuarios/42
GET /usuarios/42/pedidos?limit=3

// duas idas ao servidor pra montar uma única tela

GraphQL — o cliente descreve a forma dos dados que quer

Com GraphQL existe um único endpoint, e é o cliente quem descreve exatamente quais campos precisa, numa única consulta — mesmo que os dados venham de relações diferentes no backend. Isso resolve o over-fetching e o under-fetching do exemplo acima, mas troca simplicidade de cache (tudo passa por POST no mesmo endpoint, então cache de CDN baseado em URL não funciona de graça) por uma camada de schema e resolvers que alguém precisa manter.

query {
  usuario(id: 42) {
    nome
    pedidos(limit: 3) {
      id
      total
    }
  }
}

gRPC — contrato rígido, binário, pensado pra serviço-a-serviço

gRPC define um contrato explícito num arquivo .proto, serializa as mensagens em formato binário (Protocol Buffers, não texto) e roda sobre HTTP/2. O ganho é performance e tipagem forte entre serviços internos — mas o payload binário não dá pra inspecionar direto no navegador ou num curl simples, e chamar gRPC a partir de um navegador exige uma camada extra (grpc-web), o que o torna mais raro entre cliente e servidor voltado ao público.

service PedidosService {
  rpc BuscarPedido (PedidoRequest) returns (PedidoResponse);
}

message PedidoRequest {
  int32 id = 1;
}

Quando cada um faz mais sentido

REST     → API pública, consumida por muitos clientes diferentes,
            se beneficia de cache HTTP tradicional (CDN, navegador)
GraphQL  → clientes com necessidades de dados bem diferentes entre si
            (app mobile vs. painel web), evitando múltiplas idas ao servidor
gRPC     → comunicação interna entre microsserviços, onde performance e
            contrato tipado importam mais que legibilidade humana do payload

Nenhum dos três é "sempre melhor" — GraphQL não elimina a necessidade de pensar em cache, e gRPC não é uma boa escolha só porque é rápido, se o consumidor da API é um navegador comum.