Curso
Importación intermedia de datos en Python
2 h
208.8K
Las APIs son la columna vertebral de las aplicaciones web y móviles modernas. Casi todas las apps de tu móvil y cada sitio web que visitas usan APIs para obtener e interactuar con los datos que ves en pantalla.
REST y GraphQL son dos de los paradigmas de diseño de APIs más comunes. En esta guía veremos las diferencias fundamentales, sus ventajas y los mejores casos de uso para que elijas el enfoque que más te convenga para tu proyecto o proyectos.
Espera, ¿qué es una API?
Si eres totalmente nuevo en el concepto de API (Application Programming Interface), echa un vistazo a nuestro curso Streamlined Data Ingestion with Pandas. Te enseñará cómo las aplicaciones pueden usar APIs para comunicarse con otros programas —y viceversa— sin que ninguna de las dos conozca los detalles del funcionamiento interno de la otra. El curso te convertirá en experto en las reglas y protocolos que usan las aplicaciones para solicitar e intercambiar información.
¿Qué es REST?
REST (Representational State Transfer) es un estilo arquitectónico usado desde principios de los 2000 para desarrollar servicios web. Define un conjunto de restricciones y principios para crear APIs escalables y sin estado. Las APIs REST (también llamadas RESTful) están pensadas para ser ligeras y se pueden usar en cualquier lenguaje o plataforma que soporte HTTP.
Si eres nuevo en las APIs REST, te recomiendo acostumbrarte a interactuar con ellas antes de desarrollar la tuya. Te ayudará a entender cómo funcionan y cuáles son las mejores prácticas. Échale un ojo a Intermediate Importing Data in Python o Intermediate Importing Data in R para empezar. Ambos cursos incluyen capítulos sobre hacer solicitudes HTTP, scraping web y otras cosas divertidas.
Conceptos clave de las APIs REST
Vamos a entender los conceptos de REST.
Sin estado (stateless)
Cada interacción entre el cliente y el servidor es independiente. El servidor no guarda datos de sesión del cliente entre solicitudes, lo que significa que cada petición debe contener toda la información necesaria para entenderla y procesarla.
Basado en recursos
Cada pieza de datos o funcionalidad se trata como un recurso que puede identificarse y manipularse mediante un identificador único, normalmente un URI (Uniform Resource Identifier).
Por ejemplo, en una aplicación de comercio electrónico, los recursos pueden incluir clientes, productos, pedidos, etc. Cada recurso se identifica con un URI único que actúa como la dirección donde se puede acceder al recurso. Por ejemplo:
-
/productspodría referirse a la colección de todos los productos. -
/products/123podría referirse a un producto concreto con el ID123.
Métodos HTTP
Las APIs RESTful suelen usar métodos HTTP estándar para operar sobre los recursos:
-
GET: recuperar datos del servidor (p. ej., obtener una lista de productos). -
POST: enviar datos al servidor (p. ej., crear un producto nuevo). -
PUT: actualizar un recurso existente (p. ej., modificar los detalles de un producto). -
DELETE: eliminar un recurso (p. ej., borrar un producto).
Una solicitud GET estándar tendría este aspecto:
Ejemplo de solicitud y respuesta REST. Imagen del autor.
Las APIs REST también usan códigos de estado HTTP estándar para comunicar errores, éxitos y otras respuestas. Y sí, ¡el estado 418 I’m a teapot existe!
Formatos de datos
Una API RESTful puede usar distintos formatos para representar e intercambiar datos, incluidos JSON, XML, HTML, texto plano, YAML y CSV.
¿Qué es GraphQL?
GraphQL es un lenguaje de consultas y un entorno de ejecución de código abierto para APIs que permite a los clientes solicitar exactamente los datos que necesitan, ni más ni menos. Lo desarrolló inicialmente Meta (antes Facebook) en 2012 para optimizar la obtención de datos en sus aplicaciones móviles y se liberó para uso público en 2015.
Conceptos clave de las APIs GraphQL
Veamos las ideas principales de GraphQL.
Consultas específicas del cliente
En GraphQL, los clientes definen la estructura de la respuesta indicando los campos que necesitan en sus consultas. Así, el cliente puede pedir solo los datos que requiere, evitando el over-fetching (recibir demasiados datos) y el under-fetching (recibir datos insuficientes).
En GraphQL, una consulta para obtener los detalles de un usuario tendría este aspecto:
Ejemplo de solicitud y respuesta GraphQL. Imagen del autor.
Queries vs. mutations
Mientras que las queries se usan para leer datos, las mutations se usan para escribir o modificar datos. Las mutations en GraphQL son análogas a las operaciones POST, PUT y DELETE en REST.
Punto de acceso único
A diferencia de las APIs REST, que pueden tener múltiples endpoints para distintos recursos, una API GraphQL suele exponer un único endpoint. Este endpoint gestiona todas las consultas y mutations, lo que simplifica la interacción del cliente con la API.
Esquema fuertemente tipado
Las APIs GraphQL se definen mediante un esquema, una definición fuertemente tipada de los modelos de datos disponibles y sus relaciones. Este esquema actúa como contrato entre cliente y servidor, garantizando que los datos devueltos coincidan con la solicitud del cliente y sean del tipo esperado.
Introspección
El esquema de GraphQL se documenta a sí mismo. Los clientes pueden usar la función de introspección para consultar el propio esquema y descubrir los tipos, queries, mutations y subscriptions disponibles, facilitando la exploración y comprensión de la API.
Datos en tiempo real
GraphQL admite actualizaciones en tiempo real mediante subscriptions. Las subscriptions permiten a los clientes recibir notificaciones cuando cambian los datos que les interesan, algo muy útil para aplicaciones en tiempo real como chats o feeds en vivo.
Diferencias clave entre GraphQL y REST
La siguiente tabla resume las diferencias clave entre las APIs GraphQL y REST.
| Aspecto | REST | GraphQL |
|---|---|---|
| Naturaleza | Arquitectónica | Lenguaje de consultas |
| Obtención de datos | Múltiples endpoints para distintos recursos (/products/123, /users/userA, etc.) | Un único endpoint con consultas flexibles. |
| Versionado | Normalmente versionado vía la URL (p. ej., /api/v1/). | Sin versionado; los cambios se gestionan haciendo evolucionar el esquema manteniendo la compatibilidad. |
| Tipos de datos | No estrictamente definidos; los clientes pueden recibir formatos de datos variables. | Esquema fuertemente tipado que define explícitamente la estructura y los tipos de datos. |
| Gestión de errores | Se usan códigos de estado HTTP para indicar errores. | Errores devueltos dentro del cuerpo de la respuesta. Sigue usando códigos de estado HTTP. |
Ventajas e inconvenientes de GraphQL y REST
Como casi todo en la vida, cada solución tiene sus ventajas y sus inconvenientes.
| Tipo de API | Pros | Contras |
|---|---|---|
| REST | - Fácil de aprender: familiar para desarrolladores con experiencia web. - Herramientas maduras: amplia documentación y prácticas de seguridad (OAuth, claves de API). |
- Over/under-fetching: puede derivar en obtención de datos ineficiente. - Versionado: requiere múltiples versiones del API. - Sin actualizaciones nativas en tiempo real: necesita tecnología adicional como WebSockets. |
| GraphQL | - Obtención eficiente: una única solicitud recupera solo los datos necesarios. - Autodocumentado: el esquema actúa como documentación siempre actualizada. - Actualizaciones en tiempo real: admite subscriptions para sincronización instantánea. |
- Curva de aprendizaje pronunciada: más complejo de aprender. - Caché compleja: la caché HTTP estándar no es efectiva; se necesita caché personalizada. - Riesgos de seguridad: las consultas flexibles pueden provocar exposiciones accidentales de datos. |
Cómo elegir entre GraphQL y REST
La elección entre REST y GraphQL dependerá por completo de las necesidades de tu proyecto. Probablemente ya te haces una idea tras la sección anterior, pero, como regla general, usa REST cuando tengas:
- Modelos de datos sencillos.
- Aplicaciones que requieren caché intensiva.
- Equipos familiarizados con las convenciones de REST.
- Necesidad de respuestas predecibles y estandarizadas.
Y opta por GraphQL cuando te enfrentes a:
- Modelos de datos complejos con relaciones anidadas.
- Aplicaciones que necesitan consultas flexibles y dinámicas.
- Iteración rápida y menos ajustes en backend.
- Actualizaciones en tiempo real.
REST y GraphQL también pueden convivir en soluciones híbridas, de modo que tu proyecto se beneficie de endpoints REST sencillos y bien definidos, y de la flexibilidad de GraphQL para recuperar datos más complejos. Por ejemplo, en una app de e-commerce, podrías usar REST para la autenticación y el registro de usuarios y aprovechar prácticas de seguridad estándar como OAuth, y usar GraphQL para obtener información más anidada y compleja como detalles de productos, categorías y reseñas de usuarios.
Conclusión
Ya lo ves: tanto GraphQL como REST tienen sus puntos fuertes y débiles y son adecuados para distintos escenarios. La elección debe guiarse por los requisitos de tu proyecto y la complejidad de tus datos.
Dicho esto, ambas herramientas son muy divertidas de usar y te pueden enseñar mucho sobre datos, así que, si tienes ocasión, ¡te recomiendo probarlas en algún momento!
Y, si después de leer esto ya tienes claro qué herramienta quieres usar, ¡estás listo para el siguiente paso! Pásate por nuestro artículo Mastering API Design: Essential Strategies for Developing High-Performance APIs para aprender a diseñar tus propias APIs.
Author
Marie Fayard
