REST vs RPC: Duas Formas de Pensar o Design de APIs

Você está projetando uma API para um novo serviço. Deve modelá-la em torno de recursos com verbos HTTP ou expor procedimentos que os clientes chamam diretamente? Isso não é apenas uma escolha de protocolo—é uma decisão fundamental sobre como você pensa a interface do seu sistema.

O design de APIs REST vs RPC representa duas mentalidades distintas, não apenas duas tecnologias. Entender quando cada abordagem brilha (e quando combiná-las) vai poupá-lo de dores de cabeça arquiteturais no futuro.

A Diferença Central de Mentalidade

REST pensa em recursos. Você tem substantivos (usuários, pedidos, produtos) e um conjunto fixo de verbos (GET, PUT, DELETE). A URL identifica o que você está operando, e o método HTTP diz como.

RPC pensa em ações. Você tem procedimentos (createUser, processPayment, generateReport) que você chama com argumentos. O foco está em o que você quer que seja feito, não no que você está operando.

Nenhum é inerentemente melhor. Eles resolvem diferentes problemas bem.

// REST: orientado a recursos
GET /users/123
PUT /users/123 { "name": "Alice" }

// RPC: orientado a ações  
POST /rpc/getUser { "id": 123 }
POST /rpc/updateUserName { "id": 123, "name": "Alice" }

Equívocos Comuns que Vale a Pena Esclarecer

REST não é “apenas JSON CRUD”. O verdadeiro REST inclui restrições como ausência de estado, capacidade de cache e sistemas em camadas. A maioria das “APIs REST” são na verdade APIs HTTP com URLs orientadas a recursos—o que é bom, mas não é a mesma coisa.

RPC não está ultrapassado. Implementações modernas como gRPC e Connect alimentam infraestruturas críticas no Google, Netflix e inúmeras startups. O gRPC roda sobre HTTP/2 e HTTP/3, com suporte de roteamento padrão na Kubernetes Gateway API.

APIs HTTP vs RPC não é binário. Muitos sistemas em produção usam REST na borda (APIs públicas, clientes de navegador) e RPC internamente (comunicação entre serviços). Este padrão híbrido é cada vez mais comum.

Compensações Práticas que Realmente Importam

Cache e Ferramentas HTTP

O modelo de recursos do REST se alinha naturalmente com o cache HTTP. Uma resposta GET /products/123 pode ser armazenada em cache por CDNs, navegadores e proxies sem qualquer configuração especial.

RPC normalmente usa POST para tudo, o que a infraestrutura HTTP trata como não-cacheável por padrão. Você pode tornar RPC cacheável, mas isso requer trabalho de design explícito.

Segurança de Tipos e Geração de Código

Frameworks RPC modernos como gRPC (com Protocol Buffers) e Connect fornecem tipagem forte e geração automática de clientes. Você define seu serviço uma vez e então gera clientes para TypeScript, Go, Python e muito mais.

REST tem OpenAPI (agora na versão 3.2, com 3.1 introduzindo alinhamento completo com JSON Schema), que oferece geração de código similar. Mas a tipagem frequentemente parece acoplada ao invés de nativa.

Streaming e Dados em Tempo Real

gRPC suporta streaming bidirecional nativamente. REST requer soluções alternativas—Server-Sent Events, WebSockets ou long-polling.

Para clientes de navegador, RPC normalmente funciona através de gRPC-Web, protocolo amigável ao HTTP do Connect, ou transcodificação JSON. Estes adicionam complexidade mas habilitam padrões de streaming que o REST puro não consegue igualar.

Tratamento de Erros

APIs REST estão cada vez mais adotando RFC 9457 (Problem Details) para respostas de erro padronizadas. Frameworks RPC têm seus próprios modelos de erro—os códigos de status do gRPC, por exemplo.

Ambos funcionam. A chave é a consistência dentro do seu sistema.

Quando Escolher o Quê

Incline-se para REST quando:

• Construir APIs públicas consumidas por clientes desconhecidos
• Cache é crítico para o desempenho
• Você quer máxima compatibilidade com ferramentas HTTP existentes
• Suas operações se mapeiam claramente para CRUD em recursos

Incline-se para RPC quando:

• Construir APIs internas entre serviços
• Você precisa de streaming ou comunicação bidirecional
• Tipagem forte e geração de código são prioridades
• Suas operações são genuinamente procedurais (“reiniciar servidor”, “executar análise”)

Use ambos quando:

• Você tem APIs voltadas ao público (REST) e microsserviços internos (RPC)
• Diferentes partes do seu sistema têm requisitos diferentes

A Realidade Híbrida

A maioria dos padrões modernos de arquitetura de API não escolhe uma abordagem exclusivamente. Uma configuração típica pode expor uma API REST através de um gateway de API para consumidores externos enquanto usa gRPC entre serviços internos para desempenho e segurança de tipos.

Isso não é um compromisso—é usar a ferramenta certa para cada contexto.

Conclusão

Comece com suas restrições. Quem consome esta API? Quais operações ela precisa suportar? Quão importante é o cache? Você precisa de streaming?

REST vs RPC não é sobre qual é “melhor”. É sobre qual mentalidade—recursos ou procedimentos—melhor se adequa ao seu problema. Frequentemente, a resposta é ambos.

Perguntas Frequentes

Truly understand users experience

See every user interaction, feel every frustration and track all hesitations with OpenReplay — the open-source digital experience platform. It can be self-hosted in minutes, giving you complete control over your customer data. . Check our GitHub repo and join the thousands of developers in our community..