REST vs GraphQL vs RPC: Quando Cada um Faz Sentido

O problema

Discussão sobre API vira dogma muito fácil.

Um lado fala que REST e o padrão serio. Outro fala que GraphQL resolve tudo. Outro trata RPC como se fosse proibido em sistema bem desenhado.

No fim, muita decisão sai pelo hype do time, não pelo formato real do problema.

O resultado costuma ser previsível:

• GraphQL onde ninguém precisava de flexibilidade de leitura
• REST forcado para ação que não e recurso
• RPC publico sem pensar em compatibilidade e observabilidade

Modelo mental

Esses tres estilos não competem pelo mesmo trabalho o tempo todo.

Pense assim:

• REST organiza a API em torno de recursos e estado.
• GraphQL organiza a leitura em torno do que o cliente quer montar.
• RPC organiza a interface em torno de ações e comandos.

Nenhum e automaticamente melhor.

Cada um otimiza uma conversa diferente.

Quebrando o problema

Antes de escolher, vale responder quatro perguntas:

1. Quem consome essa API?
2. O que domina essa fronteira: recurso, leitura agregada ou comando?
3. Onde esta a dor real: overfetch, evolução, padronizacao, latência, simplicidade?
4. Como essa interface vai ser observada, versionada e mantida?

Quando REST costuma fazer sentido

REST funciona bem quando:

• você tem recursos claros, como users, orders, products
• a interface precisa ser previsivel para vários clientes
• cache HTTP, semântica de metodo e ecossistema importam
• a API pode ser usada por parceiros ou publico externo

REST geralmente brilha pela simplicidade operacional.

Você olha para rota, metodo, status code e headers e a conversa fica compreensivel.

Quando GraphQL costuma fazer sentido

GraphQL faz mais sentido quando:

• ha muitas telas diferentes montando dados de vários lugares
• o frontend sofre com overfetch e underfetch
• você quer que o cliente escolha o shape da leitura
• o dominio combina com um grafo de dados navegavel

Mas GraphQL não e grátis.

Ele traz custo de schema, resolvers, autorização mais cuidadosa, controle de profundidade, caching menos obvio e risco de query cara.

Quando RPC costuma fazer sentido

RPC e muito bom quando:

• a operação e claramente uma ação, não um recurso
• a fronteira e interna entre serviços ou backend e backend
• você quer contrato tipado e direto
• o nome da operação comunica melhor do que um recurso genérico

Exemplos naturais:

• reserveInventory
• calculateShipping
• issueRefund
• generateInvoice

Forçar isso dentro de uma fantasia de recurso REST muitas vezes piora a clareza.

Exemplo simples

Imagine um ecommerce com tres fronteiras diferentes.

1. API publica para parceiros

Parceiros precisam listar produtos, consultar pedido e atualizar estoque.

Aqui, REST costuma ser uma boa escolha:

• semântica conhecida
• documentação fácil
• boa compatibilidade com vários clientes
• caching e status code ajudam bastante

2. Web app e app mobile do produto

Uma tela de produto precisa:

• informações do item
• estoque
• preco promocional
• recomendações
• avaliacoes

Outra tela precisa outra composição.

Aqui, GraphQL pode fazer sentido porque reduz a dor de montar leituras muito variadas para UI.

3. Comunicação interna entre serviços

O serviço de pedidos precisa pedir ao serviço de estoque:

reserveInventory

Isso e uma ação com semântica muito clara.

RPC encaixa melhor do que tentar esconder essa intenção atras de um recurso artificial.

Perceba a conclusão:

o mesmo sistema pode usar mais de um estilo sem contradição nenhuma.

Erros comuns

• Escolher GraphQL porque parece mais avancado.
• Tratar RPC como erro arquitetural mesmo quando a operação e claramente comando.
• Forcar tudo em REST e acabar com rota estranha para ações.
• Esquecer que API publica tem custo maior de compatibilidade e documentação.
• Assumir que um estilo precisa dominar 100 por cento do sistema.

Como um senior pensa

Quem tem mais experiência raramente pergunta “qual e o melhor estilo?”.

Pergunta outra coisa:

“Qual formato deixa essa fronteira mais clara, mais evoluivel e menos cara de operar?”

Essa troca de pergunta já melhora bastante a decisão.

Porque tira a conversa do gosto pessoal e leva para contrato, consumidor, manutenção e risco.

O que o entrevistador quer ver

Em entrevista, o avaliador normalmente quer ver se você sabe escolher por contexto.

Sinaliza maturidade quando você:

• explica o que cada estilo otimiza
• conecta a escolha ao tipo de consumidor
• fala de trade-off operacional, não só ergonomia
• admite mistura de abordagens quando a fronteira muda

Uma resposta forte costuma soar assim:

“Se eu tenho recurso claro e vários clientes, REST me ajuda. Se o problema principal e leitura flexivel para UI, GraphQL pode valer. Se a fronteira e interna e dominada por comandos, RPC costuma ser a interface mais honesta.”

API boa não escolhe moda. Escolhe a fronteira certa para o problema certo.