Como conductos a través de los cuales los componentes de software interactúan y los datos fluyen a través de Internet, las API son el alma de los servicios 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 de programación y una herramienta) simplifican el desarrollo de software al permitir la integración de datos y servicios de terceros. Las API también permiten a las empresas ofrecer funciones de servicio e intercambio de datos seguros a empleados, socios comerciales y usuarios.
A pesar de los muchos tipos de API que existen, los debates sobre dos paradigmas principales han dominado la conversación en los últimos años: REST (transferencia de estado representacional) y GraphQL. Ambos ofrecen una serie de beneficios y, por lo tanto, se utilizan en proyectos de redes en todo el mundo. Sin embargo, se diferencian significativamente en la forma en que gestionan el tráfico de datos. Aquí analizamos esas diferencias y analizamos cómo las empresas pueden utilizar las API REST y GraphQL para optimizar sus redes.
Es necesario conocer las API REST y GraphQL por separado para poder compararlas.
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 utilizar un protocolo de comunicación sin estado, cliente/servidor y almacenable en caché. Las API REST, también llamadas API RESTful, son las que impulsan las arquitecturas REST.
Las API REST utilizan identificadores únicos de recursos (URI) para direccionar los recursos. Las API REST funcionan haciendo que diferentes endpoints realicen operaciones CRUD ("crear", "leer", "actualizar" y "eliminar") para los recursos de la 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 habituales son JSON y XML (y a veces HTML o texto sin formato).
Cuando el cliente solicita un recurso, el servidor procesa la consulta y devuelve todos los datos asociados a ese recurso. La respuesta incluye códigos de respuesta HTTP como "200 OK" (para solicitudes REST satisfactorias) y "404 Not Found" (para recursos que no existen).
GraphQL es un lenguaje de consulta y tiempo de ejecución de API que Facebook desarrolló internamente en 2012 antes de convertirse 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 utilizar varios endpoints para obtener datos y realizar operaciones de red, GraphQL expone modelos de datos utilizando un único endpoint a través del cual los clientes envían solicitudes GraphQL, independientemente de lo que pidan. A continuación, 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 única consulta al servidor GraphQL.
Tanto GraphQL como las API REST son intercambios de datos basados en recursos que utilizan 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 un complemento eficaz y más flexible a REST; las API GraphQL se consideran a menudo una mejora de los entornos RESTful, especialmente por 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 proceso de API de una organización, ya que ayuda a solucionar los problemas que se encuentran a menudo con REST.
Sin embargo, REST fue durante mucho tiempo el estándar de las arquitecturas de API, y muchos desarrolladores y arquitectos siguen confiando en las configuraciones RESTful para gestionar sus redes de TI. Por ello, comprender las diferencias entre ambos es esencial para la estrategia de gestión de TI de cualquier organización.
Las API REST y GraphQL difieren en la forma en que gestionan:
Dado que REST se basa en múltiples endpoints e interacciones sin estado, donde cada solicitud de API se procesa como una nueva consulta, independiente de cualquier otra, los clientes reciben todos los datos asociados a un recurso. Si un cliente solo necesita un subconjunto de los datos, sigue recibiendo todos los datos (sobrecarga). Y si el cliente necesita datos que abarcan varios 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 (captación insuficiente). Las API de GraphQL utilizan un único endpoint de GraphQL para ofrecer a los clientes una respuesta de datos precisa y completa en un solo viaje de ida y vuelta a partir de una única solicitud, eliminando los problemas de sobreobtención y subobtención.
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.
Las API REST deben utilizar 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 del cliente puede devolver un código de estado 400 y un error del servidor puede devolver un código de estado 500.
A primera vista, este enfoque de los informes de estado parece más sencillo, pero los códigos de estado HTTP suelen ser más útiles para los usuarios de la web que para las propias API, especialmente en el caso de errores. REST no cuenta con 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 en absoluto. 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 GraphQL, cada solicitud (independientemente de si ha dado lugar a 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 los errores en el cuerpo de la respuesta junto con los datos, por lo que los clientes deben analizar la carga de datos para determinar si la solicitud fue exitosa.
Dicho esto, GraphQL tiene una especificación para los errores, por lo que los errores de la API son más fácilmente distinguibles de los errores de transporte. La naturaleza exacta de los errores aparece en la entrada "errores" en el cuerpo de la respuesta, lo que puede hacer que las API de GraphQL sean preferibles para construir.
REST no tiene soporte integrado para actualizaciones en tiempo real. Si una aplicación necesita funciones en tiempo real, los desarrolladores deben aplicar técnicas como el sondeo prolongado (en el que el cliente sondea repetidamente el servidor en busca de nuevos datos) y los eventos enviados por el servidor, que pueden añadir complejidad a la aplicación.
Sin embargo, GraphQL incluye soporte integrado para actualizaciones en tiempo real a través de suscripciones. Las suscripciones mantienen una conexión estable con el servidor, lo que permite al servidor enviar actualizaciones al cliente cada vez que se producen eventos específicos.
El entorno REST está bien establecido, con una amplia gama de herramientas, bibliotecas y marcos disponibles para los desarrolladores. Trabajar con API REST aun así requiere que los equipos naveguen por varios endpoints y entiendan las convenciones y patrones únicos de cada API.
Las API GraphQL son relativamente nuevas, pero el entorno GraphQL ha crecido enormemente desde su introducción, con diversas herramientas y bibliotecas disponibles tanto para el desarrollo de servidores como de clientes. Herramientas como GraphiQL y GraphQL Playground proporcionan potentes entornos de desarrollo integrados (IDE) en el navegador para explorar y probar las API de GraphQL. Además, GraphQL ofrece una gran compatibilidad con la generación de código, lo que puede simplificar el desarrollo del cliente.
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. Aunque eficaces, estas estrategias de almacenamiento en caché pueden resultar complejas de aplicar y no ser adecuadas para todos los casos de uso.
Las API de GraphQL pueden ser más difíciles de almacenar en caché debido a la naturaleza dinámica de las consultas. Sin embargo, la implementación de consultas persistentes, el almacenamiento en caché de respuestas y el almacenamiento en caché del lado del servidor puede mitigar estos desafíos y agilizar los esfuerzos de almacenamiento en caché más amplios en las arquitecturas GraphQL.
Ni las API de REST ni las de GraphQL son inherentemente superiores; son herramientas diferentes que se adaptan a diferentes tareas.
REST suele ser más fácil de implementar y puede ser una buena opción cuando se prefiere un protocolo de comunicación directo y almacenable en caché con estrictos controles de acceso (para sitios de comercio electrónico de cara al público como Shopify y GitHub, por ejemplo). Dados los riesgos de subobtención y sobreobtención, las API REST son las mejores para:
Las API 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 construir API en entornos complejos con requisitos frontales que cambian rápidamente. Esto incluye:
Aunque utilizan enfoques diferentes, tanto las API GraphQL como las REST tienen el potencial de mejorar en gran medida la escalabilidad de la red y el rendimiento del servidor.
Independientemente de si elige implementar API REST o GraphQL, o alguna combinación de ambas, su empresa 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 utilizar 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 le ayuda a crear, gestionar, proteger, socializar y monetizar API, y a promover la transformación digital en centros de datos y entornos de nube. Esto significa que tanto las empresas como los clientes pueden impulsar las aplicaciones digitales e impulsar la innovación en tiempo real.
Con API Connect, las empresas pueden ayudar a garantizar que operan a la vanguardia de la gestión de API, lo que resultará invaluable en un panorama informático que está a punto de crecer, complejizarse y competir con el tiempo.