REST vs GraphQL vs gRPC: un marco de decisión para 2026

Su equipo inicia un nuevo servicio. Alguien abre un hilo de Slack: "¿Deberíamos usar GraphQL?" Alguien más responde con un enlace a un punto de referencia gRPC. El hilo se divide en tres bandos. Dos horas después, ninguna decisión.

El problema no es la falta de información. El problema es la falta de criterio. REST, GraphQL y gRPC cada uno resolver una forma diferente de problema. Elija el incorrecto y pagará el impuesto por cada solicitud durante años. Elija el correcto y la arquitectura pasará a un segundo plano.

Esta guía le brinda un marco de decisión concreto, no "depende". Cada protocolo recibe un específico caso de uso en el que gana, un ejemplo de código que puede ejecutar y una tabla de comparación en la que puede acceder un documento de diseño.

El marco de 30 segundos

Comience con tres preguntas:

1. ¿Quién llama a esta API? ¿Desarrolladores externos, sus propios clientes frontend o servicios internos?
2. ¿Cuántas formas de datos necesita el cliente? ¿Una forma fija o muchas variaciones?
3. ¿Qué importa más: capacidad de caché, flexibilidad de consultas o rendimiento sin procesar?

Las respuestas se asignan directamente a un protocolo:

• DESCANSAR gana cuando la audiencia es externa, la forma de los datos es fija y el almacenamiento en caché es importante.
• GrafoQL gana cuando varios clientes necesitan diferentes porciones del mismo gráfico de datos.
• gRPC gana cuando los servicios internos se comunican entre sí y el rendimiento importa más que la legibilidad humana.

Aquí está la misma lógica que el código:

DESCANSO: el valor predeterminado universal

REST asigna operaciones a verbos HTTP y recursos a URL. Cada lenguaje de programación tiene un cliente HTTP. Cada CDN comprende los encabezados de la caché. Cada desarrollador ha utilizado curl.

REST es la opción correcta para las API públicas en las que usted controla la forma de los datos y los clientes esperan estabilidad y estabilidad. puntos finales documentados. Los más de 150 puntos finales API de botoi utilizan REST. Aquí hay una búsqueda de DNS:

Respuesta:

La solicitud es un solo POST. La respuesta es un objeto JSON plano. Puedes probarlo con curl, canalizarlo. a través de jq, o llamarlo desde cualquier idioma con fetch. No hay archivo de esquema para compilar, no hay lenguaje de consulta que aprender, ni paso de generación de código.

Donde el DESCANSO brilla

• API de desarrollador públicas. Los desarrolladores externos esperan REST. El coste de incorporación es cero.
• Recursos almacenables en caché. El almacenamiento en caché HTTP funciona en todas las capas: navegador, CDN, proxy inverso. A GET /users/123 La respuesta con encabezados de caché adecuados no cuesta nada en solicitudes repetidas.
• Integraciones de webhooks. Los webhooks son solicitudes HTTP POST. REST se ajusta al modelo mental.
• Operaciones CRUD simples. Cuando cada punto final hace una cosa con una forma de entrada y una forma de salida, REST no agrega gastos generales.

Donde REST se queda corto

• Sobrevaloración. Una aplicación móvil que necesita 3 campos de un perfil de usuario aún descarga el objeto completo de 40 campos.
• Insuficiente. Un panel que muestra un usuario, su equipo y su actividad reciente realiza 3 llamadas HTTP secuenciales. La latencia se acumula.
• No hay evolución de esquema incorporada. Usted versiona las URL (/v1/, /v2/) o agregue campos y espere que los clientes ignoren las claves desconocidas.

GraphQL: consultas basadas en el cliente

GraphQL permite al cliente especificar exactamente qué campos necesita en una sola solicitud. El servidor expone un esquema mecanografiado. El cliente escribe una consulta según ese esquema y recibe una respuesta diseñada para coincidir.

La API pública de GitHub lo demuestra bien. Una consulta recupera su nombre de usuario y los 3 repositorios principales con recuento de estrellas y lenguaje primario. En REST, esto requeriría al menos 2 llamadas.

Respuesta:

La clienta pidió name, stargazerCount, y primaryLanguage. El servidor devolvió exactamente esos campos. No se transfieren datos adicionales. No hay una segunda solicitud.

Donde brilla GraphQL

• Aplicaciones móviles. El ancho de banda es limitado. El tamaño de la carga útil importa. GraphQL elimina la recuperación excesiva en cada pantalla.
• Paneles de control y vistas de agregación. Una sola consulta puede extraer datos de usuarios, pedidos e inventario en un solo viaje de ida y vuelta.
• Iteración rápida de la interfaz. Los equipos de frontend cambian sus consultas sin esperar a que los equipos de backend creen nuevos puntos finales.
• Escritura fuerte. El esquema es el contrato. Las herramientas de generación de código como GraphQL Code Generator producen tipos TypeScript a partir de él.

Donde GraphQL se queda corto

• Almacenamiento en caché. Cada consulta es un POST para /graphql. El almacenamiento en caché HTTP a nivel de CDN o de navegador no funciona sin una capa de consultas persistentes o consultas basadas en GET.
• Superficie de seguridad. Los clientes pueden escribir consultas costosas que unen datos profundamente anidados. Necesita un análisis de costos de consultas y una limitación de profundidad para evitar abusos.
• Curva de aprendizaje. Los desarrolladores deben aprender el lenguaje de consulta, el diseño de esquemas, los solucionadores y los patrones de DataLoader. El tiempo de aceleración es mayor que el de REST.
• N+1 consultas. Los patrones de resolución ingenuos desencadenan una consulta de base de datos por elemento de una lista. El procesamiento por lotes de DataLoader soluciona este problema, pero debe crearlo usted mismo.

gRPC: velocidad interna

gRPC utiliza búferes de protocolo para la serialización y HTTP/2 para el transporte. Tu defines tu servicio contrato en un .proto archivo, generar código de cliente y servidor, y obtener llamadas RPC con seguridad de tipos con cargas útiles binarias.

A partir de esta definición, protoc genera stubs de cliente e interfaces de servidor en Go, Java, Python, Rust, C++ o una docena de otros lenguajes. El código generado maneja la serialización, deserialización, y encuadre HTTP/2.

Donde brilla gRPC

• Comunicación servicio a servicio. Los microservicios internos que intercambian mensajes de alta frecuencia se benefician de la serialización binaria y los flujos multiplexados.
• Contratos estrictos. La .proto El archivo es la única fuente de verdad. Los cambios importantes se detectan en tiempo de compilación, no en tiempo de ejecución.
• Transmisión bidireccional. gRPC admite transmisión de servidor, transmisión de cliente y transmisión bidireccional. Las funciones en tiempo real, como las transmisiones de transacciones en vivo, se adaptan de forma natural.
• Entornos políglotas. Un servicio Go puede llamar a un servicio Python a través de códigos auxiliares generados sin código de serialización manual.

Donde gRPC se queda corto

• Soporte del navegador. Los navegadores no pueden realizar llamadas gRPC nativas. El proxy grpc-web agrega una capa de complejidad y latencia.
• Legibilidad humana. Las cargas binarias no son inspeccionables con curl o herramientas de desarrollo del navegador. La depuración requiere herramientas especializadas como grpcurl o Bloom RPC.
• Madurez del ecosistema. REST tiene décadas de herramientas: Postman, Swagger, puertas de enlace API, limitadores de velocidad. Las herramientas gRPC están creciendo pero no al mismo nivel.
• Curva de aprendizaje. Los equipos deben aprender los búferes de protocolo, la sintaxis de proto3, los canales de generación de código y los patrones de manejo de errores específicos de gRPC.

tabla comparativa

Ejemplos de decisiones del mundo real

Stripe: REST para pagos

Stripe procesa miles de millones de dólares en pagos a través de una API REST. Sus criterios de valoración siguen lo predecible patrones: POST /v1/payment_intents, GET /v1/charges/:id. Cada desarrollador Quien integra Stripe conoce HTTP. La fricción de incorporación es cercana a cero. Stripe eligió REST porque su audiencia son desarrolladores externos que necesitan puntos finales estables, documentados y almacenables en caché.

GitHub: GraphQL para herramientas de desarrollo

GitHub migró de REST (v3) a GraphQL (v4) porque sus clientes (aplicaciones de escritorio, aplicaciones móviles, integraciones de terceros) necesitaban datos diferentes de los mismos objetos. Una herramienta de CI necesita compromiso estado y verificaciones de ejecución. Una aplicación de gestión de proyectos necesita problemas, etiquetas y asignados. Una aplicación móvil necesita una vista de perfil mínima. Un punto final REST no podría servir a los tres sin una recuperación excesiva masiva.

Google: gRPC para servicios internos

Google creó gRPC (la "g" significa una palabra diferente en cada versión) para manejar el servicio interno comunicación a escala. Cuando su red de servicios procesa millones de RPC por segundo, la diferencia entre el análisis de texto JSON y la deserialización binaria del búfer de protocolo es importante. Google eligió gRPC porque la audiencia es interna, los contratos son estrictos y el rendimiento es la principal limitación.

Por qué botoi eligió REST para más de 150 puntos finales

La API de botoi sirve puntos finales de utilidad independientes: búsquedas de DNS, validación de correo electrónico, formato JSON, código QR generación, cálculo hash. Cada punto final toma una entrada específica y devuelve una salida específica. No existe un gráfico de datos relacionales que conecte un registro DNS con un código QR.

Tres factores hicieron que REST fuera la elección clara:

• Soporte universal al cliente. Los desarrolladores llaman a botoi desde Node.js, Python, Go, Ruby, PHP, scripts de shell y agentes de IA. REST funciona en todos ellos sin configuración.
• Capacidad de caché. OBTENER puntos finales para recursos estáticos (como búsquedas de países o listas de monedas) beneficiarse del almacenamiento en caché HTTP en la capa CDN. Esto mantiene los tiempos de respuesta por debajo de 20 ms para solicitudes repetidas.
• Descubribilidad. Cada punto final tiene una URL estable, una entrada de especificación OpenAPI y una interfaz interactiva. documentos a través de Scalar. Los nuevos desarrolladores encuentran y prueban puntos finales en menos de un minuto.

GraphQL agregaría complejidad sin beneficio. No hay ningún gráfico de consulta que recorrer. gRPC lo haría excluir clientes del navegador y scripts de shell. REST es la herramienta adecuada para este tipo de problema.

Protocolos de mezcla en un solo sistema

El marco se aplica por límite, no por organización. Muchos sistemas de producción combinan protocolos:

• Capa API externa: DESCANSAR. Los desarrolladores y webhooks externos esperan HTTP + JSON.
• Gateway orientada al cliente: GráficoQL. Los clientes móviles y web consultan una puerta de enlace que agrega datos de múltiples servicios.
• Malla de servicio interna: gRPC. Los servicios backend se comunican con cargas útiles binarias y contratos estrictos.

Esto no es complejidad por la complejidad misma. Cada límite tiene una audiencia diferente con diferentes restricciones. El protocolo debe coincidir con la restricción, y no al revés.

Lista de verificación de decisiones

Copie esto en su documento de diseño. Responda cada pregunta y la elección del protocolo se volverá obvia.

1. ¿Quiénes son las consumidoras API? Desarrolladores externos (REST), tu propio equipo frontend (GraphQL), servicios internos (gRPC).
2. ¿Cuántas formas de datos solicitan los clientes? Una forma (REST), muchas formas (GraphQL), contratos fijos (gRPC).
3. ¿Importa el almacenamiento en caché HTTP? Sí (REST), a veces (GraphQL con esfuerzo), no (gRPC).
4. ¿Necesitas transmisión? No (REST está bien), suscripciones (GraphQL), bidireccional (gRPC).
5. ¿Qué idiomas usan las clientas? Todo (REST), JS/TS pesado (las herramientas GraphQL son las más potentes aquí), políglota con generación de código (gRPC).
6. ¿Cuál es la experiencia actual del equipo? Si nadie conoce los Protocol Buffers, gRPC tiene un alto costo de aumento. Si nadie conoce los solucionadores GraphQL, espere un mes de aprendizaje antes de que estén listos para la producción.

Errores comunes a evitar

• Elegir GraphQL porque parece nuevo. GraphQL agrega complejidad de resolución y consulta análisis de costos y mitigación N+1. Si su API tiene 10 puntos finales CRUD con formas fijas, REST los tiene el mismo trabajo con menos código.
• Elegir gRPC para una API pública. Sus usuarios no pueden llamar a gRPC desde un navegador, desde curl, o desde una herramienta de bajo código. De todos modos, terminarás construyendo una puerta de enlace REST frente a él.
• Elegir REST para un gráfico de datos complejo. Si su equipo frontend solicita 5 nuevos puntos finales "resumen" por sprint porque los existentes devuelven demasiados o muy pocos datos, esa es una señal de que GraphQL reduciría los gastos generales de coordinación.
• Ignorar la experiencia del equipo. El protocolo más rápido de enviar es el de su equipo. ya lo sabe. Un equipo con fluidez en REST que cambia a gRPC pasará semanas desarrollando herramientas antes escribir lógica de negocios.