IT & Engineering
Qué es una API RESTful, cómo funciona, sus ventajas y ejemplos
Las API RESTful son las API más utilizadas en el mundo de los servicios web. Utilizan solicitudes del protocolo de transferencia de hipertexto (HTTP) para crear, leer, actualizar y eliminar (CRUD) datos. Son populares por su simplicidad, escalabilidad, velocidad y capacidad para gestionar todos los tipos de datos.
En este artículo, nos adentraremos en el mundo de las API RESTful y hablaremos sobre cómo funcionan, sus usos, sus ventajas y cómo puedes usar la API de email de Mailgun para enviar, recibir y hacer un seguimiento de los emails.
¿Qué es una API?
Una interfaz de programación de aplicaciones (API) es un conjunto de reglas que utilizan dos programas de software para comunicarse entre sí e intercambiar datos.
Piensa en la última vez que pediste un bocadillo Footlong en Subway. Te dieron varias opciones en cuanto al tipo de pan, las salsas, las verduras, etc. Les indicaste tus preferencias y te prepararon el bocadillo según tus requisitos. Son capaces de hacer lo mismo por cada cliente porque han establecido un estándar de comunicación entre ellos y la clientela y han descrito todas las opciones que hay a su disposición. Los estándares que han establecido sirven como API, lo que te ayuda a realizar tu pedido y a ellos a preparar el bocadillo exactamente como te gusta.
Ahora piensa en el botón «Iniciar sesión con Google» o «Registrarse con Google» que ves en muchos sitios web. Google ha definido un estándar de comunicación entre sí mismo y todos los sitios web del mundo a través de la API «Google Sign-In for Websites». El equipo de desarrollo web toma la API y la aplica a los botones de inicio de sesión o registro de sus sitios; la API entra en acción cuando se hace clic en el botón, obtiene tus datos de Google y te ayuda a iniciar sesión con ellos.
Ahora que sabemos qué hace una API, vamos a definir rápidamente algunos de los términos que utilizaremos a lo largo del artículo.
Cliente
Un cliente es un sistema que realiza solicitudes para acceder a datos en un servidor. En la analogía de Subway, el cliente es la persona que entra a comprar un bocadillo. En el ejemplo en el que usas tu ID de Google para registrarte o iniciar sesión en un sitio web, este último es el cliente.
Servidor
Un servidor es un sistema que tiene los recursos que necesita el cliente. En el ejemplo de Subway, el servidor es el restaurante. En el ejemplo del ID de Google, Google es el servidor.
Recurso
Un recurso es cualquier dato que el servidor pueda proporcionar. En el ejemplo de Subway, el bocadillo es el recurso. En el ejemplo de Google, tu ID de usuario es el recurso.
Al hablar sobre las API, es posible que escuches el término «identificador de recursos». Un identificador de recursos no es el recurso en sí, sino un ID único asignado al recurso. Piensa en una base de datos del personal con miles de profesionales. Es probable que varias personas compartan el mismo nombre y apellido. Por eso, en las grandes empresas, a todo el mundo se le asigna un ID único para que no haya confusiones con las nóminas y los días de vacaciones. De la misma manera, al usar identificadores de recursos, las API se aseguran de que el cliente y el servidor estén en sintonía acerca de los recursos que solicita el cliente.
Tipos de solicitudes de API
Hay cuatro tipos de solicitudes de API:
- DELETE: para eliminar datos existentes
- PUT/PATCH: para actualizar datos existentes/para modificar y reemplazar datos existentes
- GET: para recuperar datos
- POST: para crear datos nuevos
¿Qué es una API RESTful y cómo funciona?
Una API RESTful es una API que cumple las restricciones arquitectónicas de la Transferencia de Estado Representacional (REST) . Estas restricciones de desarrollo (básicamente una serie de reglas que deben seguir las API) permiten que las API sean más rápidas y escalables y admitan todos los tipos de datos. Debido a esto, las API RESTful se han convertido en las API más comunes del mundo, especialmente para los servicios web.
El concepto de REST y sus seis restricciones fue introducido por primera vez por Roy Fielding en su tesis del 2000, «Architectural Styles and the Design of Network-based Software Architectures». Los parámetros ayudan al equipo de desarrollo al detallar qué incluye y qué excluye una API eficaz. Por lo tanto, aunque existen restricciones, las API RESTful son en realidad más fáciles de desarrollar, utilizar y conectar que aquellas que no son RESTful.
Vamos a analizar las seis en detalle.
Las seis restricciones arquitectónicas del marco de trabajo REST
1. Cliente-servidor
Cliente-servidor significa que los roles del servidor y del cliente están claramente definidos y diferenciados. El servidor se encarga exclusivamente del almacenamiento de datos y el cliente lee los datos (y los modifica si tiene permiso para hacerlo). De este modo, el servidor y el cliente pueden escalar y evolucionar de manera independiente.
2. Interfaz uniforme
Tener una interfaz uniforme significa que el cliente debe recibir información del servidor en un formato coherente y legible. La interfaz uniforme debe cumplir con los siguientes principios rectores:
- Hipermedia como motor del estado de la aplicación (HATEOAS): las API RESTful están impulsadas por hipermedia. Esto significa que para comprender la respuesta que envía el servidor, el cliente solo necesita comprender el hipermedia. En otro tipo de API, se necesita un lenguaje alternativo llamado lenguaje de descripción de interfaz (IDL); en las API RESTful, este no es el caso.
- Mensajes autodescriptivos: un mensaje se puede definir como cada solicitud del cliente al servidor y cada respuesta del servidor al cliente. Cada mensaje que se intercambia entre el cliente y el servidor debe contener información suficiente para procesar el mensaje. Esto significa que la solicitud que va del cliente al servidor debe identificar el recurso al que intenta acceder, así como indicar exactamente qué quiere hacer con él (crear, leer, actualizar o eliminar).
- Identificación de recursos: los recursos que se mencionan en los mensajes intercambiados entre el cliente y el servidor deben poder identificarse a través de representaciones. Esto se consigue cumpliendo con el estándar del identificador uniforme de recursos (URI). En otras palabras, un mensaje del servidor al cliente podría no contener un archivo real de su base de datos, sino una representación en HTML del mismo junto con algunos metadatos. Como la representación en HTML cumple el estándar URI, el cliente puede leerla de manera sencilla.
- Manipulación de recursos a través de representaciones: el cliente debe poder manipular (crear, leer, actualizar, eliminar) los recursos enviando al servidor una representación de cómo debe verse la versión final de los mismos. Si el cliente tiene permiso suficiente para manipular datos, el servidor debe cumplir con la solicitud.
3. Sin estado
Las API RESTful no tienen estado, lo que significa que el servidor no almacena ninguna información sobre la sesión del cliente. Durante una sesión, un cliente puede realizar varias consultas y enviar diversas solicitudes al servidor. Para que la API sea RESTful, cada solicitud debe ser autónoma y no debe contener ninguna información relacionada con solicitudes pasadas, futuras o simultáneas. De esta manera, la carga sobre el servidor se reduce considerablemente.
4. Capacidad de caché
Cuando un usuario hace una solicitud para obtener datos del servidor, la solicitud viaja del cliente al servidor a través de una caché de información almacenada. Los datos que ya están en la caché pueden recuperarse de ella sin suponer ninguna carga para el servidor.
El equipo de desarrollo debe marcar los datos que viajan del servidor al cliente como almacenables o no almacenables en caché. Los datos que se pueden almacenar en caché se guardan en la caché del cliente y se puede acceder a ellos según sea necesario, lo que agiliza el acceso a estos datos y evita cargas al servidor si el cliente quiere volver a acceder a ellos.
5. Sistema de capas
En un sistema de capas, existen varias capas y cada una de ellas tiene un propósito de alto nivel. Imagina un sistema estándar de cuatro capas: una capa de base de datos que maneja los datos, una de persistencia que gestiona cómo se conservan los datos en la base de datos, una capa de negocios que procesa todo tipo de lógica empresarial y una de presentación que transforma los datos a un formato comprensible.
Las capas están organizadas de tal manera que solo interactúan con las capas que se sitúan por encima y por debajo de ellas. A veces, en lugar de utilizar cuatro capas, el equipo de desarrollo decide optar por tres y usar una capa que sirva como capa de base de datos y de persistencia combinadas.
Tras configurar las capas, el equipo de desarrollo añade componentes de proxy y puerta de enlace y divide las distintas funciones entre las diferentes capas. El número de capas y la forma en que el equipo de desarrollo decide organizarlas depende de los requisitos del sistema.
6. Código a petición
El código a petición es la única restricción arquitectónica opcional para que una API se considere RESTful. La persona que programa debe crear la API de manera que el cliente tenga la opción de pedir un código ejecutable al servidor. Este código ejecutable suele tener formato de applet o script. Al recibir dicho código del servidor, el cliente lo ejecuta íntegramente por su cuenta.
Por ejemplo, piensa en aquellos tiempos en los que necesitábamos Adobe Flash Player para ejecutar ciertas secciones animadas en la mayoría de las páginas web y, si no lo tenías, esas secciones no se cargaban y mostraban un error.
Los componentes de una API RESTful
Las API RESTful constan de los siguientes componentes:
1. Los puntos de conexión
El punto de conexión describe la ubicación de los datos en el servidor. Los puntos de conexión son URL de los recursos a los que intentas acceder a través de la API.
2. El método
Ya hemos hablado de los cuatro métodos HTTP (GET, PUT, POST, DELETE) que usan las API para manipular datos. Una solicitud de API debe usar uno de estos métodos para que el servidor entienda qué debe hacer.
3. Los encabezados
Las API RESTful contienen encabezados HTTP que incluyen información, como metadatos, servidores proxy y tipos de conexión HTTP. En un mensaje de solicitud, el encabezado contiene información sobre la naturaleza de la solicitud, así como sobre los tipos de respuestas válidas.
En un mensaje de respuesta, el encabezado también contiene información sobre el estado de la solicitud junto con los códigos de estado. «404», por ejemplo, significa que la API no consiguió recuperar los datos solicitados del servidor.
4. Los datos (o cuerpo)
Los datos (o cuerpo) de la API RESTful consisten en información adicional sobre los recursos que solicita el cliente. En el caso de una solicitud GET simple, no se necesita más información. En una solicitud POST, el cliente declara el tipo de contenido en el encabezado y el contenido real se encuentra en el cuerpo. Podría ser un nuevo recurso que el cliente envía al servidor. El servidor comprobará si el tipo de contenido es aceptable o no y procederá a buscar el recurso en el cuerpo.
Ventajas de las API RESTful
Las API RESTful son rápidas, flexibles, escalables y versátiles. A continuación se muestran algunas de las ventajas clave de este tipo de API:
1. Admite todos los tipos de formatos de datos
En otros tipos de API, la elección de formatos de datos es limitada. Sin embargo, las API RESTful admiten todos los formatos de datos.
En las API RESTful, puedes enviar una solicitud HTTP, obtener datos en la notación de objetos de JavaScript (JSON) como respuesta y analizar esos datos para usarlos en las aplicaciones del cliente. Esto hace que sean la mejor opción para los navegadores web. Además, puedes integrar fácilmente estas API en tu sitio web existente.
3. Usa menos ancho de banda
Gracias a JSON, las API RESTful utilizan menos ancho de banda en comparación con otros tipos de API. No obstante, esto es válido solo para las API web basadas en JSON. Una API web basada en XML tendrá una carga útil similar a la de su equivalente no RESTful, independientemente de si cumple o no las restricciones arquitectónicas de REST.
4. No hace falta diseñarla desde cero
En la mayoría de los casos, puedes conseguir modelos que puedes modificar y usar. Por ejemplo, NetApp y Mailgun ofrece un tutorial completo y el código fuente para crear una API privada. En algunos casos, por ejemplo al desarrollar una API privada, tendrás que diseñarla desde cero y, para ello, puedes obtener mucha asistencia de Stack Overflow.
5. Fácil para la mayoría de desarrolladores
Las API RESTful utilizan métodos HTTP para la comunicación. Se pueden utilizar Python, JavaScript (Node.js), Ruby, C# y otros lenguajes para desarrollar estas API, lo que facilita el trabajo con ellas para la mayor parte del equipo de desarrollo.
¿Para qué se utilizan las API RESTful?
Las API RESTful son populares en el sector de SaaS, ya que resultan excelentes para los servicios web. Estas API se utilizan como:
API públicas para el acceso a datos muy utilizados
Las API de Twitter, Facebook y Google son los mejores ejemplos de API públicas. Estas API están al alcance de todos y cualquiera puede simplemente tomar el código de la API e implementarlo en su sitio web para que la base de usuarios pueda iniciar sesión con sus cuentas de redes sociales.
API privadas para el acceso a datos dentro de una organización
Las API RESTful también se emplean para la comunicación privada e interna dentro de los programas de software que se usan en una organización. Imagina una agencia que ofrece servicios de desarrollo web a su clientela. Contará con departamentos de RR. HH., finanzas, ventas, asistencia, marketing, además de producción y control de calidad (QA). Todos estos departamentos utilizarán aplicaciones de software específicas, así como otras comunes para gestionar las nóminas, las vacaciones, las evaluaciones de desempeño, etc. Todos estos programas de software tendrán que comunicarse con un repositorio de datos central que ofrezca a la junta directiva una visión general. El repositorio central de datos podrá comunicarse con todos estos programas a través de API RESTful.
API de terceros para el acceso a recursos y datos de pago
Muchas organizaciones utilizan API de terceros para la comunicación entre sus programas de software y los de sus socios o clientela. Un buen ejemplo de esto sería la API de email de Mailgun. Puedes usar esta API para integrar el email en tus aplicaciones de ventas y marketing.
Para cualquier persona que use tu software interno, en realidad no ha cambiado nada, salvo que ahora dispone de algunas funcionalidades nuevas: puede enviar campañas de email mediante el mismo software que ya usaba para la gestión de contenidos, el marketing, la interacción con los clientes, las ventas y la asistencia. Sin embargo, a nivel interno, la API RESTful de Mailgun se encarga de transferir las solicitudes de tu aplicación de software a Mailgun y devolver respuestas.
Usa la API de Mailgun para llevar tus emails al siguiente nivel
La API de Mailgun se integra con tu software existente y abre la puerta a campañas de email más sencillas y potentes. La API puede recopilar y modificar los datos de los clientes desde tu CRM y otras herramientas, lo que te permite enviar emails de forma masiva a segmentos de tu audiencia, modificar y gestionar listas de contactos, además de profundizar en analíticas detalladas sobre el comportamiento de la clientela respecto a los emails. La API de email de Mailgun es RESTful, lo que significa que se integra con todos los proveedores de email. También se ha diseñado teniendo en cuenta la seguridad y la fidelidad para mitigar los riesgos en torno a los datos de la base de usuarios y garantizar que los emails acaben en las bandejas de entrada, no en las carpetas de spam.
¿Necesitas más información sobre la API de email de Mailgun? Puedes encontrarla aquí.