La discusión sobre REST vs GraphQL suele plantearse como si hubiera un ganador. No lo hay: son dos maneras distintas de escribir el contrato entre quien publica los datos y quien los consume, y cada una traslada el trabajo a un lugar diferente de la arquitectura.
Esta guía ordena la decisión con lenguaje de negocio: qué cambia realmente entre un estilo y otro, qué síntomas indican que el contrato actual ya no alcanza, qué se gana y qué se paga en cada camino, y cómo se mapea la elección a los servicios administrados de AWS.
El contrato es la decisión, no la tecnología
En una API REST el servidor publica un conjunto de direcciones y cada una devuelve una estructura definida de antemano. El cliente pide /clientes/123 y recibe el cliente completo, tal como el servidor decidió que se ve un cliente. Si además necesita sus últimos pedidos, pide otra dirección. La forma de la respuesta la controla quien publica la API.
En una API GraphQL el servidor publica un esquema: el catálogo completo de datos disponibles, sus tipos y sus relaciones. El cliente escribe en cada llamada qué campos quiere y de qué entidades, y recibe exactamente eso. La forma de la respuesta la controla quien consume la API.
Ese desplazamiento —del servidor al cliente— es toda la decisión. Todo lo demás son consecuencias.
Los dos síntomas que anticipan el cambio
Antes de discutir estilos conviene reconocer los síntomas. Son dos y se sienten en la aplicación, no en el diagrama:
- Over-fetching: llega de más. La pantalla necesita el nombre y el saldo del cliente, pero la respuesta trae también su dirección, su historial de contacto y sus preferencias. Se paga transferencia, se paga proceso y se paga batería en el dispositivo por datos que nadie mira. En una red móvil promedio esto se nota.
- Under-fetching: no alcanza con una. Para armar el detalle de un pedido hay que llamar al pedido, después al cliente, después a cada producto. Cada llamada agrega su propia latencia, y la pantalla termina siendo tan lenta como la suma de todas.
Cuando estos dos síntomas aparecen juntos y de forma sistemática, el problema ya no se resuelve agregando direcciones nuevas: se resolvió mal el contrato.
Cacheo: la diferencia más subestimada
Esta es la dimensión donde REST conserva una ventaja estructural que muchas comparaciones omiten.
En REST, cada dirección identifica un recurso y la respuesta viaja con las cabeceras estándar de HTTP. Eso significa que el navegador, la red de distribución de contenido y cualquier capa intermedia pueden cachear la respuesta sin saber nada de la aplicación. Es cacheo gratuito, heredado de cómo funciona la web.
En GraphQL las consultas llegan por un único punto de entrada y con cuerpo variable, así que esa infraestructura ya no puede decidir sola qué guardar. El cacheo se traslada a la capa de aplicación: caché por entidad, caché de resultados de resolutor o caché administrada por la plataforma. Es perfectamente resoluble —AWS AppSync ofrece cacheo del lado del servidor como capacidad del servicio— pero es trabajo que en REST no había que hacer.
La lectura práctica: si buena parte del rendimiento de tu API hoy proviene del cacheo por dirección, migrar a GraphQL sin diseñar la estrategia de caché equivalente empeora el resultado.
Versionado: dos maneras de no romper a nadie
En REST el patrón consolidado es publicar una versión nueva de la dirección y sostener la anterior mientras los consumidores migran. Es explícito y fácil de comunicar, y también acumula: cada versión viva es código que hay que mantener y probar.
En GraphQL no se versiona el punto de entrada: se hace evolucionar el esquema. Se agregan campos y tipos sin tocar los existentes, y los que se van a retirar se marcan como obsoletos para que los clientes los abandonen de a poco. La ventaja es que no hay versiones paralelas. La condición es que se sepa qué campo consume cada cliente — sin esa visibilidad, retirar un campo es una apuesta.
Observabilidad y control del costo de las consultas
Aquí la asimetría se invierte y conviene decirlo con claridad.
En REST, cada dirección es una unidad de medida natural: se sabe cuántas veces se llamó, cuánto tardó y cuánto falló, y se puede poner un límite por cliente sobre esa dirección. La lectura operativa es directa.
En GraphQL, todas las consultas entran por el mismo punto. Sin instrumentación por campo y por resolutor, el panel muestra un solo punto de enlace con latencia promedio y no dice nada útil. Peor: una consulta mal escrita por un cliente puede pedir relaciones anidadas en profundidad y hacer trabajar al back end mucho más que cien llamadas REST. Por eso una operación GraphQL sana necesita, desde el primer día, métricas por campo, límites de profundidad y de complejidad de consulta, y tiempos de espera por resolutor. No es opcional: es la condición para operar.
Seguridad: la superficie cambia de forma
Los dos estilos comparten los mecanismos de autenticación y autorización —identidad federada, tokens, autorizadores propios— pero la superficie a proteger es distinta.
En REST la autorización se aplica de forma natural por dirección y método: quién puede leer un recurso, quién puede modificarlo. En GraphQL la autorización debe aplicarse por campo, porque una única consulta puede atravesar varias entidades con niveles de sensibilidad distintos. Autorizar solo la entrada del esquema deja abierta la puerta a que un cliente autenticado navegue por relaciones que no le corresponden.
A eso se suman dos controles propios de GraphQL: limitar la profundidad de anidamiento para evitar consultas que exploten combinatoriamente, y decidir si la introspección del esquema queda expuesta en producción.
REST vs GraphQL: comparación por dimensión
| Dimensión | REST | GraphQL |
|---|---|---|
| Quién define la respuesta | El servidor, por dirección | El cliente, por consulta |
| Llamadas para armar una vista | Varias, encadenadas | Una sola |
| Over-fetching / under-fetching | Frecuentes por diseño | Se evitan por diseño |
| Cacheo | Nativo de HTTP, sin código | En capa de aplicación, se diseña |
| Evolución del contrato | Versiones paralelas | Esquema evolutivo con campos obsoletos |
| Autorización | Por dirección y método | Por campo del esquema |
| Observabilidad | Directa, por dirección | Requiere métricas por campo y resolutor |
| Servicio administrado en AWS | Amazon API Gateway | AWS AppSync |
Cómo se resuelve cada estilo en AWS
Ninguno de los dos caminos exige operar servidores de API propios.
Amazon API Gateway cubre el estilo REST con dos variantes que no son equivalentes. Las REST APIs traen el conjunto completo de capacidades de gestión: claves de API, límites de uso por cliente, validación de solicitudes, respuestas cacheadas, integración con AWS WAF, puntos de enlace privados y trazas con AWS X-Ray. Las HTTP APIs ofrecen un conjunto reducido de funciones —por ejemplo, no incluyen cacheo, claves de API ni integración con AWS WAF— a cambio de un modelo más simple. La documentación de AWS es explícita: si necesitas claves de API, límites por cliente, validación de solicitudes, AWS WAF o puntos de enlace privados, la variante correcta es REST API.
AWS AppSync cubre el estilo GraphQL. Expone un único punto de enlace que puede leer de varias fuentes de datos a la vez, permite combinar varias APIs GraphQL en una API fusionada, resuelve suscripciones en tiempo real y canales de publicación y suscripción sobre WebSockets administrados, ofrece cacheo del lado del servidor, y trae controles de autorización con claves de API, IAM, Amazon Cognito, proveedores OpenID Connect y autorizadores propios con AWS Lambda. La lógica de resolución se escribe en JavaScript y TypeScript.
Ambos servicios se integran con AWS Lambda, con servicios de AWS y con back ends existentes, así que la elección del estilo no condiciona dónde vive tu lógica de negocio.
El árbol de decisión, sin romanticismo
Quédate en REST cuando:
- La API es pública y la consumen terceros que esperan el contrato estándar de la industria.
- La integración es de sistema a sistema, con un puñado de operaciones estables.
- El cacheo por dirección explica buena parte de tu rendimiento actual.
- El equipo aún no tiene la práctica operativa para gobernar un esquema compartido.
Considera GraphQL cuando:
- Hay varios clientes —web, móvil, socios— consumiendo los mismos datos con necesidades distintas.
- Armar una pantalla exige encadenar tres o más llamadas de forma sistemática.
- El equipo de front end queda bloqueado esperando direcciones nuevas del back end.
- La aplicación necesita actualizaciones en tiempo real como parte del producto, no como añadido.
Y el camino más común en organizaciones con sistemas heredados no es elegir: es mantener las APIs REST de cada dominio como fuente de verdad y publicar una capa GraphQL por encima que componga esos datos para las aplicaciones de cara al usuario. Funciona bien siempre que el esquema tenga dueño y gobierno, y no crezca por acumulación.
Cómo lo abordamos en Caleidos
Cuando acompañamos una modernización de aplicaciones, la capa de APIs se decide con el mismo criterio que el resto de la arquitectura: qué patrón de consumo real tienen los clientes, qué tolera la operación y qué equipo va a sostenerlo. No migramos un contrato completo porque el estilo nuevo sea más moderno; empezamos por el dominio donde el síntoma se siente y medimos antes de extender.
Si aún estás ordenando los conceptos base, la guía qué es una API explica el mecanismo desde cero, y qué son los microservicios muestra por qué la conversación de APIs y la de arquitectura de servicios llegan siempre juntas.
Preguntas frecuentes
¿Cuál es la diferencia entre REST y GraphQL? Quién decide la forma de la respuesta. En REST la define el servidor por cada dirección; en GraphQL la define el cliente en cada consulta sobre un esquema publicado.
¿GraphQL reemplaza a REST? No. Resuelve mejor el caso de muchos clientes con necesidades distintas sobre los mismos datos. REST sigue siendo la respuesta correcta en APIs públicas, integraciones simples y escenarios donde el cacheo por dirección aporta el rendimiento.
¿Qué se pierde al pasar a GraphQL? El cacheo gratuito de HTTP y la lectura operativa directa por dirección. Ambas cosas se recuperan, pero con diseño y trabajo explícito.
¿Qué servicios de AWS uso? Amazon API Gateway para REST —variante REST API si necesitas claves, límites por cliente, validación, AWS WAF o puntos de enlace privados— y AWS AppSync para GraphQL.
¿Quieres decidir la capa de APIs con tu caso sobre la mesa?
Conversemos sobre tu caso: en 30 minutos revisamos cómo consumen tus aplicaciones los datos hoy, dónde se está pagando el contrato equivocado y qué camino ordena esa capa sin detener lo que ya está en producción.
