REST o gRPC: cuándo conviene cada uno, y por qué su core no habla ninguno

La pregunta «¿REST o gRPC?» suele plantearse como si hubiera que elegir un bando para toda la arquitectura. En la práctica, casi nunca se decide una sola vez: se decide en cada frontera. Una API que reciben terceros, una llamada entre dos servicios del mismo equipo y la conexión con un sistema de hace veinte años piden respuestas distintas.

Es la profundización de la rama «en línea» de nuestro artículo sobre en línea o asíncrono: allá se decide cuándo conviene responder al instante, y aquí con qué protocolo hacerlo y qué hacer cuando el sistema del fondo no puede.

Este artículo es para el equipo técnico que tiene que tomar esas decisiones: arquitectos, líderes de desarrollo y quienes integran sistemas en bancos, aseguradoras, fintechs o retail. Propone un criterio que se resume en una frase:

REST en la frontera, gRPC en el corazón, adaptador para el legacy.

Es un criterio, no una regla; al final se ven los casos en que conviene romperlo.

Qué es gRPC, en cinco ideas

gRPC es un marco de llamadas a procedimientos remotos (RPC). En lugar de pensar en recursos y URL, se piensa en servicios con métodos que se invocan a distancia como si fueran locales. Cinco ideas lo definen:

1. El contrato va primero. El servicio y sus mensajes se describen en un archivo .proto. Por defecto, gRPC usa Protocol Buffers (Protobuf) como lenguaje de definición de interfaces, tanto para el servicio como para la estructura de los mensajes [1]. Del .proto se generan el cliente y la base del servidor, tipados, en los lenguajes que el equipo use [4].
2. Va sobre HTTP/2 y viaja en binario. gRPC está diseñado para HTTP/2, que ofrece empaquetado binario, compresión y multiplexación de varias llamadas sobre una sola conexión TCP. Protobuf produce mensajes pequeños y se serializa con rapidez. Un matiz que conviene no perder: HTTP/2 no es exclusivo de gRPC; una API HTTP con JSON también puede usarlo [4].
3. Streaming de primera clase. Además de la llamada simple (una petición, una respuesta), existen el streaming del servidor al cliente, del cliente al servidor y el bidireccional. gRPC garantiza el orden de los mensajes dentro de una misma llamada [1]. Sirve para telemetría, cotizaciones en vivo o notificaciones.
4. Plazos (deadlines) explícitos. El cliente indica cuánto está dispuesto a esperar; si se vence, la llamada termina con el error DEADLINE_EXCEEDED [1]. Por defecto gRPC no fija ningún plazo, de modo que un cliente puede quedar esperando prácticamente para siempre [2]. Al vencer el plazo, gRPC cancela la llamada, pero la aplicación debe detectar esa cancelación y detener el trabajo que lanzó [2]. El plazo puede propagarse a las llamadas que ese servicio hace a otros, para no gastar recursos en una respuesta que ya nadie espera [2][4].
5. Estados de error con vocabulario propio. Cada llamada termina con un código de estado de un catálogo de 17 valores, entre ellos INVALID_ARGUMENT, NOT_FOUND, PERMISSION_DENIED, UNAUTHENTICATED, RESOURCE_EXHAUSTED y UNAVAILABLE [3]. La página oficial de códigos no define una equivalencia con los códigos HTTP. Quien exponga el servicio hacia fuera debe decidir esa traducción por escrito.

gRPC no es «REST más rápido»: es otro modelo, con contrato obligatorio y una especificación estricta que, según Microsoft, evita el debate sobre el formato de URL, verbos y códigos de respuesta [4]. Si además se expondrá HTTP/JSON, esas rutas, verbos y errores igual hay que definirlos. Y no es gratis: el formato binario no se lee a simple vista y requiere el contrato para interpretarse [4].

Cuándo REST

REST es un estilo de diseño sobre HTTP orientado a recursos, verbos y representaciones, casi siempre en JSON. Es la opción por defecto en la frontera: donde su sistema se encuentra con quien no controla.

• Terceros e integradores. Quien consume su API no tiene por qué adoptar su herramienta de generación de código. REST/JSON reduce la dependencia de SDK generados y facilita la inspección y las pruebas manuales; un socio puede probar una llamada con curl en un minuto.
• Frontend en el navegador. Ningún navegador da el control sobre HTTP/2 que gRPC necesita, por lo que no se puede llamar a un servicio gRPC directamente desde una página [4]. Más adelante se ve qué hacer cuando de todos modos se quiere gRPC en la web.
• Depuración humana. Una petición REST se lee, se copia, se pega en un ticket y se reproduce. Con gRPC se necesitan herramientas que entiendan el formato [4].

Cuándo gRPC

Considere gRPC cuando usted controle proveedor y consumidor, acepte gobernar los .proto y tenga una restricción medida de latencia, tamaño de mensaje o volumen. Los escenarios que la documentación de Microsoft recomienda son microservicios de baja latencia y alto rendimiento, comunicación punto a punto en tiempo real, entornos con varios lenguajes, redes con restricciones de ancho de banda y comunicación entre procesos de una misma máquina [4].

• Servicios internos. Entre servicios del mismo dominio de confianza, el contrato fuerte y el cliente generado evitan una categoría entera de errores: campos que cambian de nombre, tipos que se interpretan distinto, clientes escritos a mano que se desfasan.
• Contrato fuerte entre equipos. Cuando varios equipos y lenguajes comparten servicios, el .proto funciona como acuerdo ejecutable: si no compila, no se integra.
• Volumen. Cuando se hacen muchas llamadas pequeñas, el tamaño del mensaje y la multiplexación sobre una conexión se notan. Mida con su carga antes de justificar el cambio con la velocidad.
• Streaming. Si el caso de uso es un flujo (precios, eventos de dispositivos, avance de un proceso largo), gRPC lo ofrece como parte del contrato, no como un añadido.

Hay un caso que Microsoft excluye: la difusión masiva a muchos clientes conectados; gRPC no tiene el concepto de «broadcast» y cada llamada transmite por separado [4].

El navegador y gRPC-Web

Como el navegador no puede hablar gRPC nativo, existe gRPC-Web: un protocolo adaptado, con un cliente generado en JavaScript y un proxy compatible (el tutorial oficial usa Envoy) entre el navegador y el servicio gRPC; además puede requerir configuración de CORS [5].

Tiene límites que conviene conocer antes de decidir. En el repositorio del proyecto, el streaming del servidor al cliente solo se admite en el modo grpcwebtext, y el streaming del cliente y el bidireccional no están soportados [6]. Microsoft lo clasifica entre las razones para preferir otro marco cuando la API debe ser accesible desde el navegador: gRPC-Web ofrece soporte, pero con limitaciones y con un proxy de servidor adicional [4].

Regla práctica: gRPC-Web si la aplicación web es suya y la plataforma ya usa Protobuf; REST/JSON si la consumirán terceros.

Exponer gRPC como REST sin escribir dos veces la lógica

No hay que escoger entre las dos caras. El contrato .proto puede llevar anotaciones HTTP (google.api.http) que dicen qué ruta y verbo corresponden a cada método. Un componente intermedio, normalmente el gateway o un proxy, convierte la petición HTTP/JSON a llamada gRPC y devuelve la respuesta en JSON. Este mecanismo se llama transcoding [4][7][18]:

Cliente REST  → gateway (transcoding) → servicio gRPC → adaptador → core legacy
Cliente gRPC  ──────────────────────→ servicio gRPC → adaptador → core legacy

Dos ejemplos de gateways que lo ofrecen, como categoría y no como recomendación:

• Envoy tiene el filtro gRPC-JSON transcoder, que permite que un cliente REST con JSON envíe peticiones por HTTP y sean enviadas a un servicio gRPC. Requiere conocer el descriptor Protobuf del servicio y las anotaciones HTTP en el contrato [7].
• Apache APISIX tiene el plugin grpc-transcode, que transforma peticiones y respuestas entre HTTP y gRPC. Los protos se registran por su API de administración, como texto o como descriptor binario [8]. La documentación consultada no menciona streaming; compruébelo en su versión.

La idea: una sola implementación, dos formas de llamarla.

Dos cuidados, que el transcoding no resuelve solo:

• Errores. El conversor traduce códigos, pero la política de qué significa cada uno para un tercero la define usted. Un UNAVAILABLE interno ¿se muestra como un error de servicio no disponible o se reintenta antes?
• Seguridad. Autenticación, autorización fina y cuotas son preocupaciones del gateway y del servicio, no del formato.

Herramientas de prueba: qué sigue vigente

Probar un servicio gRPC a mano pide una herramienta que entienda Protobuf. Este es el estado que verificamos el 6 de octubre de 2026; cualquier cambio posterior puede modificarlo.

La reflexión de servidor permite descubrir métodos sin el .proto, pero debe habilitarse en el servicio y, en producción, conviene decidir a quién se le muestra.

Java: Spring Boot y Quarkus

Java es un caso útil porque ambos marcos tienen un camino documentado hacia gRPC. Las versiones que siguen son las verificadas el 6 de octubre de 2026.

Spring Boot. Spring gRPC es un proyecto oficial de Spring, con versión 1.0.0 publicada el 4-dic-2025. Al corte, la versión estable más reciente en GitHub es la 1.1.1 (21-ago-2026) [15]. La 1.1.0 (10-jun-2026) migró la autoconfiguración a Spring Boot 4.1.0, y las ramas 1.0.x apuntan a Boot 4.0 [15]. Para una base nueva en Spring Boot 4.1 hay camino oficial; con versiones anteriores, revise la compatibilidad con la línea 1.0.x.

Quarkus. gRPC se incorpora con la extensión quarkus-grpc: implementa y consume servicios, genera código a partir del .proto, se integra con el modelo reactivo, admite TLS y TLS mutuo, xDS y comunicación en proceso [16]. Quarkus recomienda el servidor gRPC basado en Vert.x porque es más flexible y está mejor integrado en el ecosistema, y ese servidor puede atender HTTP y gRPC por el mismo puerto, si se configura quarkus.grpc.server.use-separate-server=false [16]. En Maven Central, la última versión 3.x de la extensión al corte es la 3.40.1 (30-sep-2026); también hay una 4.0.0.Beta1 de ese mismo mes, que es una versión previa [16].

Los dos funcionan: decide el marco que el equipo ya domina.

Sea cual sea el marco, importan las mismas prácticas: un repositorio único de contratos, interceptores para identidad y trazas, política de errores común, health checks y plazos obligatorios en cada cliente.

Evolución de contratos Protobuf: cómo no romper a nadie

El contrato es el producto. Cambiarlo sin cuidado rompe a los clientes que no se enteraron. La guía oficial de Protobuf establece reglas claras [17]:

• Agregar campos es seguro. El código viejo ignora los campos nuevos al leer, y el nuevo usa valores por defecto con mensajes antiguos.
• Agregar valores a un enum es seguro en el formato binario; aun así, valide que los clientes y las reglas de negocio contemplen el valor nuevo (en lenguajes con enums cerrados, como Java, un valor desconocido llega como un caso aparte).
• El número de un campo no se cambia ni se reutiliza una vez que el mensaje está en uso, porque ese número identifica al campo en el formato de cable.
• Al retirar un campo, se reserva su número (y, si se usa JSON, también su nombre) para que nadie lo reutilice por accidente.
• Mover campos hacia o desde un oneof existente es riesgoso: puede perderse información al serializar y leer.

La guía de diseño de APIs de Google aplica tanto a REST como a RPC y remite a sus propuestas AIP-180 (compatibilidad) y AIP-185 (versiones) [18]. La regla operativa es corta:

1. Publicar los .proto como producto versionado.
2. Validar compatibilidad en la integración continua (con una herramienta de detección de cambios que rompen).
3. Mantener pruebas de contrato entre el servicio y sus consumidores.
4. Tratar cualquier cambio no aditivo como una versión nueva de la API, con periodo de convivencia.

Por qué su core no habla ninguno

Aquí está el punto que casi ningún comparativo de protocolos toca. Los sistemas centrales de una aseguradora, un banco o un comercio con décadas de historia suelen no hablar ni REST ni gRPC, y sus limitantes explican por qué:

• No exponen APIs que se puedan llamar, ni avisan cuando algo cambia.
• Solo aceptan datos en una zona de intercambio, tablas o archivos, y los procesan a su propio ritmo, a menudo por lotes, disparando un proceso propio.
• Aguantan poca carga: una ráfaga de llamadas en línea los satura.
• La respuesta llega cuando termina el proceso, no cuando se envió la petición, y a veces solo se encuentra volviendo a leer otra tabla o archivo.

Elegir REST o gRPC para la capa de arriba no cambia eso. Lo que se necesita en medio es un adaptador: un componente que habla el idioma del core hacia adentro y el contrato nuevo hacia afuera. Y cuando el modelo, los errores, la seguridad o las transacciones de los dos lados no coinciden, el adaptador debe ser una capa anticorrupción, el patrón que Eric Evans describió en Domain-Driven Design [19].

Es una fachada entre subsistemas que no comparten semántica, para que las dependencias externas no limiten el diseño de la aplicación; puede ser un componente interno o un servicio independiente [19].

La diferencia con un proxy es importante:

Cuatro tareas suelen caer en el adaptador, y conviene escribirlas antes de que se diluyan en el código (criterio de diseño; el patrón en sí se describe en [19]):

• Traducir los objetos de datos y validar invariantes en esa frontera, incluido el saneamiento de entradas.
• Normalizar errores: un código de retorno propietario o una fila en una tabla de errores se vuelve un estado gRPC, y de ahí, si procede, un código HTTP, con la política explícita de la que se habló arriba.
• Proteger al core. Un core tiene un ritmo que soporta. Si una emisión masiva envía miles de movimientos y el core procesa unas decenas por minuto, la llamada en línea no es la forma de entregarlos: se necesita una cola o un mecanismo de nivelación de carga [20], salvo que el llamador requiera una respuesta síncrona de baja latencia. Una cola exige definir idempotencia, reintentos, manejo de mensajes fallidos, orden cuando aplique y consulta de estado por identificador de correlación [20]. Ese es el tema del siguiente artículo de esta serie.
• Observar: un identificador de correlación en cada llamada, para reconstruir qué pasó entre el contrato nuevo y el core, y registros estructurados para diagnosticar fallas de traducción.

Costos: más latencia, un servicio más que operar y decidir si la capa es permanente [19]. Microsoft recomienda que se limite a traducir y no concentre reglas de negocio ni orquestación [19].

Tabla de decisión

Cuándo romper la frase guía

«REST en la frontera, gRPC en el corazón, adaptador para el legacy» funciona como punto de partida. Hay casos razonables en que conviene salirse:

• Todo REST. Con equipo pequeño, volumen moderado y sin streaming, Protobuf puede costar más de lo que da.
• gRPC hasta la frontera. Si los consumidores externos son pocos y aceptan SDK generados, se evita una capa.
• Sin adaptador. Si el core ya ofrece una API moderna y estable, el adaptador se reduce a un mapeo delgado.
• Asíncrono en lugar de síncrono. Si el problema es el ritmo del core y no el protocolo, lo que ayuda es una cola, un evento o un callback con identificador de correlación.

Lo que sí conviene mantener: decidir por frontera, medir antes de justificar y escribir el contrato antes de escribir el código.

Cierre: lo que conviene llevarse a la próxima reunión

Antes de elegir protocolo, tres preguntas ordenan la discusión: quién consume la interfaz y quién controla sus clientes, qué idioma habla el sistema del fondo y qué ritmo soporta. Si el sistema del fondo no habla ninguno de los dos o va más lento que quien lo llama, y la carga medida exige desacoplar la entrada del procesamiento, conviene priorizar el adaptador y considerar una cola antes de cambiar de protocolo.

Qué hace Hábil

Hábil trabaja en el espacio entre los sistemas existentes y las capas nuevas: busca que un core que no habla REST ni gRPC pueda atender a sus canales y a sus socios sin frenar la operación. Para unir sus APIs y canales, véase la página Unificar su operación y sus canales; para actualizar el core a su ritmo, Modernizar el core sin frenar el negocio. La primera conversación, sin costo, parte del mapa de sus integraciones y de los puntos donde un contrato o un core con ritmo limitado podrían costarle dinero, tiempo o evidencia. Escríbanos por WhatsApp.

Consultadas el 6-oct-2026. Las versiones y fechas de herramientas y de proyectos cambian; las marcadas [proveedor] son cifras o estados que publica el propio proveedor.