REST vs RPC: Dos Formas de Pensar en el Diseño de APIs

Jan 14, 2026 · 4 min read

REST vs RPC: Dos Formas de Pensar en el Diseño de APIs

Estás diseñando una API para un nuevo servicio. ¿Deberías modelarla en torno a recursos con verbos HTTP, o exponer procedimientos que los clientes llamen directamente? Esto no es solo una elección de protocolo—es una decisión fundamental sobre cómo piensas en la interfaz de tu sistema.

El diseño de APIs REST vs RPC representa dos mentalidades distintas, no solo dos tecnologías. Comprender cuándo cada enfoque brilla (y cuándo combinarlos) te ahorrará dolores de cabeza arquitectónicos en el futuro.

Puntos Clave

REST se enfoca en recursos (sustantivos) con verbos HTTP estándar, mientras que RPC se enfoca en acciones (procedimientos) llamadas con argumentos
REST se alinea naturalmente con el caché HTTP y la infraestructura web existente, mientras que RPC sobresale en seguridad de tipos y streaming
La mayoría de los sistemas en producción usan ambos: REST para APIs públicas y RPC para comunicación interna entre servicios
La elección depende de tus restricciones: quién consume la API, necesidades de caché, requisitos de streaming, y si las operaciones son basadas en recursos o procedimentales

La Diferencia Fundamental de Mentalidad

REST piensa en recursos. Tienes sustantivos (usuarios, pedidos, productos) y un conjunto fijo de verbos (GET, PUT, DELETE). La URL identifica sobre qué estás operando, y el método HTTP dice cómo.

RPC piensa en acciones. Tienes procedimientos (createUser, processPayment, generateReport) que llamas con argumentos. El enfoque está en qué quieres que se haga, no en sobre qué estás operando.

Ninguno es inherentemente mejor. Resuelven diferentes problemas bien.

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

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

Conceptos Erróneos Comunes que Vale la Pena Aclarar

REST no es “solo CRUD en JSON”. El verdadero REST incluye restricciones como ausencia de estado, capacidad de caché y sistemas en capas. La mayoría de las “APIs REST” son en realidad APIs HTTP con URLs orientadas a recursos—lo cual está bien, pero no es lo mismo.

RPC no está obsoleto. Implementaciones modernas como gRPC y Connect impulsan infraestructura crítica en Google, Netflix e innumerables startups. gRPC funciona sobre HTTP/2 y HTTP/3, con soporte de enrutamiento estándar en Kubernetes Gateway API.

APIs HTTP vs RPC no es binario. Muchos sistemas en producción usan REST en el perímetro (APIs públicas, clientes de navegador) y RPC internamente (comunicación entre servicios). Este patrón híbrido es cada vez más común.

Compromisos Prácticos que Realmente Importan

Caché y Herramientas HTTP

El modelo de recursos de REST se alinea naturalmente con el caché HTTP. Una respuesta GET /products/123 puede ser almacenada en caché por CDNs, navegadores y proxies sin ninguna configuración especial.

RPC típicamente usa POST para todo, lo cual la infraestructura HTTP trata como no cacheable por defecto. Puedes hacer que RPC sea cacheable, pero requiere trabajo de diseño explícito.

Seguridad de Tipos y Generación de Código

Los frameworks RPC modernos como gRPC (con Protocol Buffers) y Connect proporcionan tipado fuerte y generación automática de clientes. Defines tu servicio una vez, luego generas clientes para TypeScript, Go, Python y más.

REST tiene OpenAPI (ahora en versión 3.2, con 3.1 introduciendo alineación completa con JSON Schema), que ofrece generación de código similar. Pero el tipado a menudo se siente añadido en lugar de nativo.

Streaming y Datos en Tiempo Real

gRPC soporta streaming bidireccional de forma nativa. REST requiere soluciones alternativas—Server-Sent Events, WebSockets o long-polling.

Para clientes de navegador, RPC típicamente funciona a través de gRPC-Web, el protocolo HTTP-friendly de Connect, o transcodificación JSON. Estos añaden complejidad pero habilitan patrones de streaming que REST puro no puede igualar.

Manejo de Errores

Las APIs REST adoptan cada vez más RFC 9457 (Problem Details) para respuestas de error estandarizadas. Los frameworks RPC tienen sus propios modelos de error—los códigos de estado de gRPC, por ejemplo.

Ambos funcionan. La clave es la consistencia dentro de tu sistema.

Cuándo Elegir Qué

Inclínate hacia REST cuando:

Construyas APIs públicas consumidas por clientes desconocidos
El caché sea crítico para el rendimiento
Quieras máxima compatibilidad con herramientas HTTP existentes
Tus operaciones se mapeen claramente a CRUD sobre recursos

Inclínate hacia RPC cuando:

Construyas APIs internas entre servicios
Necesites streaming o comunicación bidireccional
El tipado fuerte y la generación de código sean prioridades
Tus operaciones sean genuinamente procedimentales (“reiniciar servidor”, “ejecutar análisis”)

Usa ambos cuando:

Tengas APIs públicas (REST) y microservicios internos (RPC)
Diferentes partes de tu sistema tengan diferentes requisitos

La Realidad Híbrida

La mayoría de los patrones modernos de arquitectura de APIs no eligen exclusivamente un enfoque. Una configuración típica podría exponer una API REST a través de un API gateway para consumidores externos mientras usa gRPC entre servicios internos para rendimiento y seguridad de tipos.

Esto no es un compromiso—es usar la herramienta correcta para cada contexto.

Conclusión

Comienza con tus restricciones. ¿Quién consume esta API? ¿Qué operaciones necesita soportar? ¿Qué tan importante es el caché? ¿Necesitas streaming?

REST vs RPC no se trata de cuál es “mejor”. Se trata de qué mentalidad—recursos o procedimientos—se ajusta mejor a tu problema. A menudo, la respuesta es ambos.

Preguntas Frecuentes

Sí, y muchos sistemas en producción hacen exactamente esto. Un patrón común expone APIs REST a través de un API gateway para consumidores externos mientras usa gRPC para comunicación interna entre servicios. Este enfoque aprovecha la compatibilidad de REST con la infraestructura web y el rendimiento y seguridad de tipos de RPC donde cada uno importa más.

gRPC típicamente ofrece mejor rendimiento debido a la serialización binaria de Protocol Buffers y el multiplexado de HTTP/2. Sin embargo, la diferencia puede ser insignificante para muchas aplicaciones. REST con JSON es a menudo suficientemente rápido, y sus ventajas de caché pueden superar las diferencias de velocidad pura. Elige basándote en tus requisitos reales de rendimiento en lugar de benchmarks teóricos.

Ambos enfoques soportan métodos de autenticación estándar. REST típicamente usa encabezados HTTP como Authorization con tokens Bearer o claves API. gRPC también usa encabezados de metadatos para tokens. La lógica de autenticación permanece similar, pero los interceptores de gRPC proporcionan una forma limpia de manejar autenticación en todos los procedimientos, mientras que REST a menudo usa middleware en la capa HTTP.

Tienes varias opciones. Crear endpoints orientados a acciones como POST /orders/123/cancel, usar métodos HTTP personalizados, o aceptar que algunas operaciones se modelan mejor como llamadas RPC. Muchas APIs usan REST para la mayoría de las operaciones pero añaden endpoints estilo RPC para procedimientos complejos. La pureza importa menos que la claridad y usabilidad para tus consumidores.

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..