GraphQL vs REST

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

GraphQL y REST son dos enfoques para construir una API, la capa a través de la cual un frontend pide datos a un backend. REST lo organiza todo alrededor de recursos, cada uno con su propia URL. Obtienes un usuario de un endpoint, sus pedidos de otro, los artículos de cada pedido de un tercero. GraphQL expone un único endpoint y un esquema, y el cliente envía una consulta que describe exactamente los datos que quiere, recibiendo de vuelta esa forma y nada más.

La diferencia se nota sobre todo en dos problemas a los que REST es propenso. El over-fetching es cuando un endpoint devuelve más campos de los que necesitas. El under-fetching es cuando una llamada no basta y tienes que hacer varias para armar una pantalla. Una página de perfil móvil en REST podría llamar a tres endpoints y tirar la mitad de lo que llega. La misma página en GraphQL es una consulta que devuelve precisamente los campos que la pantalla renderiza, y por eso las apps preocupadas por el ancho de banda suelen preferirla.

Ninguno gana de forma rotunda. REST es más simple, se apoya en el caché HTTP que toda la web ya entiende y es fácil de razonar para un acceso a recursos sencillo. GraphQL da flexibilidad al cliente y reduce los viajes de ida y vuelta, pero mueve la complejidad al servidor, complica el caché y exige cuidado con el coste de las consultas para que una sola petición no pueda pedir demasiado. La elección correcta depende del cliente, de la forma de los datos y de quién consume la API.

GraphQL y REST en Dallonses

No tenemos favorito de la casa. Elegimos según el problema. Un cliente que construía una plataforma de contenidos con muchos tipos de cliente y datos profundamente anidados se llevó GraphQL, porque la flexibilidad pagaba de verdad su sobrecoste y dejaba a sus equipos de frontend avanzar sin esperar a nuevos endpoints. Otro cliente necesitaba una API pública limpia y cacheable para partners, y REST era la respuesta obvia y honesta. Forzar GraphQL ahí habría añadido complejidad para nada.

Ambas decisiones son parte de cómo abordamos el desarrollo API-first. Elegimos el estilo antes de escribir el contrato, sopesamos con el cliente las consecuencias de caché y tooling, y nos comprometemos con uno en lugar de atornillar un segundo para tapar una mala primera decisión. El objetivo es una API con la que los propios ingenieros del cliente puedan convivir durante años, no la que mejor se lee en una propuesta.

¿Decidiendo entre GraphQL y REST para una API nueva? Elijamos la que encaja.

Habla con nosotros sobre diseño de APIs