COMPARATIVA

REST vs GraphQL

GraphQL nació para resolver un problema concreto de REST: pedir tres veces al servidor para pintar una pantalla, y que cada respuesta traiga el triple de datos de los necesarios. Resuelve eso, y a cambio trae complejidad propia.

LA DIFERENCIA

En REST el servidor decide qué devuelve cada endpoint; el cliente coge lo que hay, aunque solo necesite dos campos de veinte. En GraphQL el cliente escribe la forma de la respuesta y recibe exactamente eso, en una sola petición. La flexibilidad se paga en caché —mucho más difícil— y en el riesgo de consultas que tumban el servidor.

CARA A CARA
Comparación entre REST y GraphQL
DimensiónRESTGraphQL
EndpointsUno por recursoUno solo
Quién decide la respuestaEl servidorEl cliente
Datos de más o de menosHabitualSe evita por diseño
Peticiones para una pantallaVariasUna
Caché HTTPDirecta, es su punto fuerteDifícil: todo es POST al mismo sitio
Curva de aprendizajeBajaNotable, en cliente y en servidor
Riesgo operativoBajoConsultas anidadas que saturan el servidor
VersionadoPor URL: /v1, /v2Evolutivo: se añaden campos y se deprecan
Contrato y tipadoDocumentado aparte (OpenAPI)El esquema ES el contrato, y se introspecciona
Cuándo REST

Por defecto, y especialmente cuando la API es pública, cuando la caché importa, o cuando los consumidores son pocos y conocidos.

Cuándo GraphQL

Cuando hay muchos clientes distintos con necesidades muy distintas —web, móvil, integraciones— y el coste de mantener endpoints a medida para cada uno se ha vuelto el cuello de botella.

El error que se comete

Adoptar GraphQL en un proyecto con un solo frontend. El problema que resuelve —muchos consumidores con necesidades divergentes— no existe ahí, y lo que llega es la complejidad sin el beneficio: perder la caché HTTP gratis y ganar una capa más que mantener. Si el síntoma es que una pantalla hace cinco llamadas, casi siempre sale más barato crear un endpoint que devuelva justo lo que esa pantalla necesita que reescribir la API entera.