GraphQL vs API REST: ¿Cuál es la diferencia?

Las API, conductos a través de los cuales interactúan los componentes de software y fluyen los datos por Internet, son el alma de los servicios sitio web contemporáneos. Las tecnologías API como SOAP (un protocolo de mensajería de servicios web), REST (un estilo arquitectónico) y GraphQL (un lenguaje y herramienta de programación) simplifican el desarrollo de software al permitir la integración de datos y servicios de terceros. Las API también permiten a las compañías ofrecer funciones de servicio seguras e intercambio de datos a empleados, asociados de negocios y usuarios.

A pesar de los muchos tipos de API, los debates sobre dos paradigmas principales dominaron la conversación en los últimos años: REST (transferencia de estado representacional) y GraphQL. Ambos ofrecen una variedad de beneficios y, por lo tanto, se despliegan para proyectos de redes en todo el mundo. Sin embargo, difieren significativamente en la forma en que gestionan el tráfico de datos. Aquí, analizamos esas diferencias y analizamos cómo las compañías pueden usar las API REST y GraphQL para optimizar sus redes.

Es necesario comprender las API REST y GraphQL individualmente para poder realizar una comparación entre ambas.

REST

Desarrollado a principios de la década de 2000, REST es un estilo arquitectónico estructurado para aplicaciones hipermedia en red, que está diseñado para emplear un protocolo de comunicación sin estado, cliente/servidor y almacenable en caché. Las API REST, también llamadas API RESTful, son los impulsores de las arquitecturas REST.

Las API REST emplean identificadores de recursos únicos (URI) para abordar los recursos. Las API REST funcionan haciendo que diferentes endpoints realicen operaciones CRUD ("crear", "leer", "actualizar" y "eliminar") para los recursos de red. Se basan en un formato de datos predefinido, llamado tipo de medio o tipo MIME, para determinar la forma y el tamaño de los recursos que proporcionan a los clientes. Los formatos más comunes son JSON y XML (y, a veces, HTML o texto sin formato).

Cuando el cliente aplicar un recurso, el servidor procesa la consulta y devuelve todos los datos asociados con ese recurso. La respuesta incluye códigos de respuesta HTTP como "200 OK" (para solicitudes REST correctas) y "404 Not Found" (para recursos que no existen).

graphql

GraphQL es un lenguaje de consulta y tiempo de ejecución de API que Facebook desarrolló internamente en 2012 antes de que se convirtiera en código abierto en 2015.

GraphQL se define mediante un esquema API escrito en el lenguaje de definición de esquemas GraphQL. Cada esquema especifica los tipos de datos que el usuario puede consultar o modificar, y las relaciones entre los tipos. Un solucionador respalda cada campo de un esquema. El resolver proporciona instrucciones para convertir consultas GraphQL, mutaciones y suscripciones en datos, y recupera datos de bases de datos, servicios en la nube y otras fuentes. Los solucionadores también proporcionan especificaciones de formato de datos y permiten al sistema unir datos de varias fuentes.

A diferencia de REST, que suele emplear varios endpoints para obtener datos y realizar operaciones de red, GraphQL expone modelos de datos mediante un único endpoint a través del cual los clientes envían solicitudes de GraphQL, independientemente de lo que aplicar. Luego, la API accede a las propiedades de los recursos y sigue las referencias entre recursos para obtener al cliente todos los datos que necesita de una sola consulta al servidor GraphQL.

Tanto GraphQL como REST API son intercambios de datos basados en recursos que emplean métodos HTTP (como solicitudes PUT y GET) que dictan qué operaciones puede realizar un cliente. Sin embargo, existen diferencias clave entre ellos que explican no solo la proliferación de GraphQL, sino también por qué los sistemas RESTful tienen tanto poder de permanencia.

GraphQL ofrece una adición eficiente y más flexible a REST; Las API de GraphQL a menudo se consideran una actualización de los entornos RESTful, especialmente dada su capacidad para facilitar la colaboración entre los equipos de front-end y back-end. GraphQL proporciona el siguiente paso lógico en el recorrido de la API de una organización, ayudando a arreglar los problemas que a menudo se encuentran con REST.

Sin embargo, REST fue durante mucho tiempo el estándar para las arquitecturas de API, y muchos desarrolladores y arquitectos siguen confiando en las configuraciones RESTful para gestionar sus redes de TI. Como tal, comprender las distinciones entre los dos es parte integral de la estrategia de gestión de TI de cualquier organización.

Las API REST y GraphQL difieren en la forma en que gestionan:

Recuperación de datos

Debido a que REST se basa en múltiples endpoints e interacciones sin estado (donde cada solicitud de API se procesa como una nueva consulta, independientemente de cualquier otra), los clientes reciben todos los datos asociados con un recurso. Si un cliente necesita solo un subconjunto de los datos, aún así recibe todos los datos (sobreobtención). Y si el cliente necesita datos que abarcan múltiples recursos, un sistema RESTful a menudo hace que el cliente consulte cada recurso por separado para compensar la recuperación inadecuada de datos de la solicitud inicial (subobtención). Las API de GraphQL emplean un único endpoint de GraphQL para dar a los clientes una respuesta de datos precisa y completa en un solo viaje de ida y vuelta desde una sola solicitud, eliminando los problemas de sobre y subcaptación.

Mantenimiento de versiones

En una arquitectura REST, los equipos deben versionar las API para modificar las estructuras de datos y evitar errores del sistema e interrupciones del servicio para el usuario final. En otras palabras, los desarrolladores deben crear un nuevo endpoint cada vez que realizan cambios, lo que crea múltiples versiones de la API y puede complicar el mantenimiento. GraphQL reduce la necesidad de versiones porque los clientes pueden especificar sus requisitos de datos en la consulta. La adición de nuevos campos al servidor no afecta a los clientes sin necesidad de esos campos. Por el contrario, si los campos están en desuso, los clientes pueden seguir solicitándolos hasta que se actualicen las consultas.

Manejo de errores

Las API REST deben usar códigos de estado HTTP para indicar el estado o el éxito de una solicitud, y cada código de estado tiene un significado específico. Una solicitud HTTP correcta devuelve un código de estado 200, mientras que un error de cliente puede devolver un código de estado 400 y un error de servidor puede devolver un código de estado 500.

A primera vista, este enfoque de los reportes de estado parece más sencillo, pero los códigos de estado HTTP suelen ser más útiles para los usuarios sitio web que para las propias API, especialmente en el caso de errores. REST no tiene una especificación para errores, por lo que los errores de API pueden aparecer como errores de transporte o no aparecer con el código de estado. Esta dinámica puede obligar al personal a leer la documentación de estado para comprender qué significan los errores o incluso cómo se comunican los errores dentro de la infraestructura.

Con las API de GraphQL, cada solicitud, independientemente de si resultó en un error, devuelve un código de estado 200 OK porque los errores no se comunican mediante códigos de estado HTTP (excepto los errores de transporte). En cambio, el sistema comunica errores en el cuerpo de la respuesta junto con los datos, por lo que los clientes deben analizar la carga útil de datos para determinar si la solicitud fue exitosa.

Dicho esto, GraphQL tiene una especificación para errores, por lo que los errores de API se distinguen más fácilmente de los errores de transporte. La naturaleza exacta de los errores aparece en la entrada "errors" en el cuerpo de la respuesta, lo que puede hacer que las API de GraphQL sean preferibles para construir.

Datos en tiempo real

REST no tiene soporte integrado para actualizaciones en tiempo real. Si una aplicación necesita funcionalidad en tiempo real, los desarrolladores generalmente deben implementar técnicas como el sondeo largo (donde el cliente sondea repetidamente al servidor en busca de nuevos datos) y eventos enviados por el servidor, que pueden agregar complejidad a la aplicación.

Sin embargo, GraphQL incluye soporte integrado para actualizaciones en tiempo real a través de subscripciones. Las subscripciones mantienen una conexión estable con el servidor, lo que permite que el servidor envíe actualizaciones al cliente cada vez que ocurren eventos específicos.

Herramientas y entorno

El entorno REST está bien establecido, con una amplia gama de herramientas, bibliotecas y marcos a disposición de los desarrolladores. Trabajar con API REST requiere, no obstante, que los equipos naveguen por varios endpoints y comprendan las convenciones y patrones únicos de cada API.

Las API de GraphQL son relativamente nuevas, pero el entorno GraphQL ha crecido enormemente desde su introducción, con varias herramientas y bibliotecas disponibles para el desarrollo de servidores y clientes. Herramientas como GraphiQL y GraphQL Playground proporcionan potentes entornos de desarrollo integrados (IDE) en el navegador para explorar y probar las API GraphQL. Además, GrapQL tiene un fuerte soporte para la generación de código, lo que puede simplificar el desarrollo del cliente.

Almacenamiento en caché

Las API REST se basan en mecanismos como etiquetas electrónicas y encabezados de última modificación para almacenar en caché las llamadas a la API. Si bien son efectivas, estas estrategias de almacenamiento en caché pueden ser complejas de implementar y pueden no ser adecuadas para todos los casos de uso.

Las API de GrapQL pueden ser más difíciles de almacenar en caché debido a la naturaleza dinámica de las consultas. Sin embargo, el despliegue de consultas persistentes, el almacenamiento en caché de respuestas y el almacenamiento en caché del lado del servidor pueden mitigar estos desafíos y optimizar los esfuerzos de almacenamiento en caché más amplios en las arquitecturas de GraphQL.

Ni las API de REST ni las de GraphQL son inherentemente superiores; son herramientas diferentes que se adaptan a diferentes tareas.

REST es generalmente más fácil de implementar y puede ser una buena opción cuando se prefiera un protocolo de comunicación sencillo y almacenable en caché con controles de acceso estrictos (por ejemplo, para sitios de comercio electrónico públicos como Shopify y GitHub). Dados los riesgos de subestimación y sobreexplotación, las API de REST son las mejores para:

• Compañías que emplean aplicaciones más pequeñas con perfiles de datos más simples
• Compañías sin requisitos complejos de consulta de datos
• Compañías donde la mayoría de la base de clientes emplea datos y operaciones de manera similar

Las API de GraphQL permiten una obtención de datos más flexible y eficiente, lo que puede mejorar el rendimiento del sistema y la facilidad de uso para los desarrolladores. Estas características hacen que GraphQL sea especialmente útil para crear API en entornos complejos con requisitos de front-end que cambian rápidamente. Esto incluye:

• Compañías con ancho de banda limitado que desean limitar las llamadas y las respuestas
• Compañías que desean combinar puntos de datos en un solo punto final
• Compañías cuyas solicitudes de clientes varían significativamente

Aunque emplean enfoques diferentes, tanto GraphQL como las API REST tienen el potencial de mejorar en gran medida la escalabilidad de la red y el rendimiento del servidor.

Independientemente de si elige desplegar API REST o GraphQL, o alguna combinación de ambas, su compañía puede beneficiarse de una amplia gama de aplicaciones potenciales, incluidas implementaciones en varios lenguajes de programación (como JavaScript) e integración con microservicios y arquitecturas sin servidor. Con IBM API Connect, puede emplear ambos tipos de API para optimizar su infraestructura de TI.

IBM API Connect es una solución de gestión de API de ciclo de vida completo que lo ayuda a crear, gestionar, proteger, socializar y monetizar API, y promover la transformación digital en centros de datos y entornos de nube. Esto significa que tanto las compañías como los clientes pueden impulsar las aplicaciones digitales y estimular la innovación en tiempo real.

Con API Connect, las compañías pueden ayudar a garantizar que están operando a la vanguardia de la gestión de API, lo que resultará invaluable en un panorama informático que está a punto de crecer más, más complejo y más competitivo con el tiempo.