REST y GraphQL resuelven el mismo problema —permitir que dos sistemas se comuniquen— con filosofías distintas. Elegir entre ambos sin entender el contexto del proyecto es una de las decisiones técnicas más sobrevaloradas en discusiones de arquitectura.
REST organiza la comunicación alrededor de recursos y verbos HTTP: obtienes un cliente con GET, lo actualizas con PUT, lo eliminas con DELETE. Es predecible, se cachea fácilmente en el navegador y en CDNs, y prácticamente cualquier desarrollador lo entiende sin curva de aprendizaje adicional. Es nuestra opción por defecto para APIs públicas o integraciones con terceros, porque la documentación y las herramientas del ecosistema son universales.
GraphQL invierte el control: el cliente pide exactamente los campos que necesita en una sola solicitud, sin sobre-pedir ni sub-pedir datos. Esto resuelve un problema real de REST en aplicaciones móviles con conexión limitada, donde cada solicitud extra cuesta batería y datos. También evita el problema clásico de "necesito tres llamadas distintas para armar esta pantalla".
La desventaja de GraphQL es la complejidad operativa: cachear respuestas es más difícil porque cada consulta puede ser distinta, y proteger contra consultas maliciosamente costosas (anidar relaciones sin límite) requiere controles adicionales que en REST vienen dados por la propia estructura de endpoints.
En un proyecto reciente de dashboard con múltiples fuentes de datos anidadas —usuarios, transacciones, reportes cruzados— GraphQL redujo el número de llamadas de red de doce a una sola por vista, mejorando notablemente el tiempo de carga percibido. En cambio, para una API de integración con un ERP externo que solo consume tres recursos simples, REST fue la opción más rápida de implementar y más fácil de documentar para el equipo del cliente.
La pregunta correcta no es cuál tecnología es superior, sino qué tan compleja y anidada es la información que tu aplicación necesita consumir, y quién va a mantener esa API en el futuro. Documentamos esa decisión igual que cualquier otra decisión de arquitectura, para que no dependa de la preferencia personal de quien construyó el sistema.