Programación · web · API

REST vs GraphQL

Estás construyendo una API y la primera gran bifurcación es el estilo: REST o GraphQL. Resuelven el mismo problema — dejar que los clientes lean y escriban datos por HTTP — pero ponen el control en manos distintas. Esta guía los compara con honestidad en obtención de datos, caché, complejidad y herramientas, para que elijas con los ojos abiertos.

La diferencia fundamental

• REST — muchos endpoints (URL), cada uno devolviendo una forma fija de datos. Llamas a /users/42 y obtienes lo que ese endpoint está hecho para devolver. El servidor decide la forma.
• GraphQL — un solo endpoint donde el cliente envía una consulta nombrando exactamente los campos que quiere, y recibe solo esos. El cliente decide la forma.

Ambos van sobre HTTP y normalmente hablan JSON. La diferencia: quién controla lo que vuelve.

La misma petición, de las dos formas

Obtener el nombre de un usuario y los títulos de sus posts. En REST suelen ser dos llamadas; en GraphQL una consulta precisa:

-- REST (a menudo dos viajes)
GET /users/42
GET /users/42/posts

-- GraphQL (una consulta, campos exactos)
POST /graphql
{ user(id: 42) { name posts { title } } }

Over-fetching y under-fetching

Es el argumento estrella de GraphQL. Con las respuestas fijas de REST, a menudo te topas con:

• Over-fetching — el endpoint devuelve mucho más de lo que necesitas (decenas de campos para mostrar un nombre).
• Under-fetching — un endpoint no basta, así que haces varias llamadas más para montar una pantalla.

GraphQL evita ambos: el cliente pide exactamente los campos que necesita, en una consulta. Para apps con muchas pantallas (sobre todo móviles), esa precisión es la razón principal para adoptarlo.

Dónde REST sigue ganando

• Caché — URL distintas + GET hacen que REST funcione de forma natural con cachés HTTP y CDN. GraphQL (POST a un endpoint) necesita caché de cliente o consultas persistidas.
• Simplicidad — para datos orientados a recursos, REST es menos que aprender y operar; sin esquema, resolvers ni límites de coste de consulta.
• Herramientas y ubicuidad — REST está en todas partes, con herramientas maduras y gratuitas y una curva de aprendizaje suave.

Dónde gana GraphQL

• Datos flexibles y precisos — los clientes obtienen exactamente lo que necesitan, nada más.
• Menos viajes — datos relacionados en una sola consulta en vez de varias llamadas.
• Un esquema tipado — un contrato autodocumentado y herramientas potentes (introspección, codegen).

El coste: más complejidad de servidor (esquema, resolvers, protección frente a consultas caras) y un caché que debes diseñar en vez de obtener gratis.

Cómo elegir

• Elige REST para API más simples, orientadas a recursos, donde el caché HTTP gratuito, la ubicuidad y una curva suave importan.
• Elige GraphQL cuando los clientes tienen necesidades de datos variadas y cambiantes y quieres evitar el over/under-fetching — y puedes asumir la complejidad de servidor extra.
• Ambos está bien — muchos sistemas exponen REST para acceso simple/público y GraphQL para apps cliente ricas.

Preguntas frecuentes

¿Cuál es la diferencia entre REST y GraphQL?

REST y GraphQL son dos estilos para construir una API web. Una API REST expone muchas URL (endpoints), cada una devolviendo una forma fija de datos — llamas a /users/42 y obtienes lo que ese endpoint devuelve. GraphQL expone un solo endpoint donde el cliente envía una consulta describiendo exactamente qué campos quiere, y recibe solo esos. En resumen: con REST el servidor decide la forma de la respuesta por endpoint; con GraphQL el cliente la decide por petición. Ambos van sobre HTTP y normalmente intercambian JSON.

¿Es GraphQL mejor que REST?

Ninguno es universalmente mejor — intercambian problemas distintos. GraphQL brilla cuando los clientes necesitan datos flexibles y precisos (p. ej. pantallas móviles variadas) porque evita el over-fetching y el under-fetching y agrupa muchas llamadas en una consulta. REST brilla para API simples orientadas a recursos y se beneficia de un caché HTTP gratuito y maduro y buenas herramientas. GraphQL añade complejidad de servidor (esquema, resolvers, control del coste de consultas); REST puede requerir varios viajes de ida y vuelta. Elige según las necesidades de datos de tus clientes, no según la moda.

¿Qué son el over-fetching y el under-fetching?

El over-fetching es cuando un endpoint devuelve más datos de los que necesitas — pides un usuario y recibes decenas de campos para mostrar un nombre, malgastando ancho de banda. El under-fetching es cuando un endpoint no devuelve lo suficiente, así que haces varias llamadas más para montar lo que una pantalla necesita. REST es propenso a ambos porque cada endpoint tiene una respuesta fija. GraphQL los evita dejando que el cliente pida exactamente los campos que necesita en una sola consulta — su principal atractivo.

¿REST o GraphQL es más fácil de cachear?

REST suele ser más fácil de cachear. Como REST usa URL distintas y métodos HTTP (sobre todo GET para lecturas), funciona de forma natural con el caché HTTP, los CDN y el caché del navegador indexados por la URL. GraphQL normalmente envía las consultas como POST a un solo endpoint, así que el caché HTTP estándar no se aplica de inmediato, y dependes de cachés del cliente (como Apollo) o consultas persistidas. Si el caché HTTP estándar y gratuito te importa mucho, es un punto a favor de REST.

En resumen

REST y GraphQL no son enemigos — son dos respuestas a «¿quién decide la forma de la respuesta?». REST la mantiene en el servidor con endpoints simples y cacheables; GraphQL se la entrega al cliente para consultas precisas y flexibles, a costa de más complejidad. Elige según las necesidades de datos de tus clientes y tu apetito por la complejidad operativa — y recuerda que puedes usar ambos donde cada uno encaje.