¿Qué es una API REST?

Introducción

Las API están cambiando la forma en que las empresas diseñan, crean e implementan aplicaciones de software.

La arquitectura monolítica ha dado paso a soluciones basadas en sistemas débilmente acoplados. microservicios. Los desarrolladores pueden concentrarse en las funcionalidades básicas mientras usan diferentes tipos de API para acceder e incorporar funciones y características creadas por otros especialistas.

REST se ha convertido rápidamente en uno de los estilos arquitectónicos más populares para crear aplicaciones y servicios basados ​​en web.

Descubra cómo funcionan las API REST y utilícelas para desarrollar soluciones innovadoras de negocio y orientadas al cliente.

Definición de API REST

La transferencia de estado representacional (REST) ​​es un estilo arquitectónico híbrido para desarrollar aplicaciones basadas en red. REST define un conjunto de restricciones (principios) que deben aplicarse a los elementos arquitectónicos (componentes, conectores y datos) y la relación entre esos elementos.

API que se adhieren a las restricciones REST se denominan API REST o RESTful.

Restricciones de la API REST

REST tiene seis (6) restricciones arquitectónicas que sirven como pautas de alto nivel para diseñar sistemas de software distribuido.

Al aplicar restricciones REST, los desarrolladores pueden inducir y mejorar las propiedades no funcionales de un sistema de software. Éstos incluyen:

• Portabilidad
• Escalabilidad
• Visibilidad
• Fiabilidad
• Eficiencia de la red
• Rendimiento percibido por el usuario
• Sencillez
• Capacidad de evolución
• Checkout Extensibility

Muchas API HTTP se anuncian como RESTful aunque no cumplan con todas las restricciones REST formales descritas en disertación de Roy Fielding. Esto ha dado lugar a animados debates en la comunidad de desarrolladores sobre lo que constituye una verdadera API RESTful.

Los desarrolladores normalmente se refieren a la Modelo de madurez de Richardson para determinar el nivel en el que una API se adhiere a los principios RESTful.

Separación cliente-servidor

En una arquitectura cliente-servidor, el componente cliente usa un conector para enviar solicitudes a un componente servidor.

El servidor realiza o rechaza el servicio solicitado y envía una respuesta al cliente. Un servidor escucha continuamente las solicitudes y, por lo general, atiende a varios clientes.

Las aplicaciones de cliente y servidor no dependen entre sí y pueden desarrollarse, modificarse o reemplazarse de forma independiente.

Este separación de intereses mejora la portabilidad de una interfaz de usuario, como un navegador web, a través de múltiples plataformas y mejora la escalabilidad de los componentes del servidor, como bases de datos.

Comunicación sin estado

El servidor debe comprender cada solicitud de cliente individualmente sin derivar contexto o información de solicitudes anteriores. Este tipo de comunicación cliente-servidor, donde el receptor no retiene el estado de la sesión de solicitudes anteriores, se denomina protocolo de comunicación sin estado.

La apatridia mejora:

• Visibilidad - El servidor no necesita mirar más allá de una sola solicitud.
• Fiabilidad - El sistema puede recuperarse de fallas de manera más eficiente.
• Escalabilidad - Los servidores requieren menos recursos ya que no es necesario almacenar datos de sesiones anteriores.
• Sencillez - Ya no es necesario administrar recursos a través de múltiples solicitudes.

Sin embargo, los protocolos sin estado también inflan la cantidad de interacciones cliente-servidor y pueden aumentar la sobrecarga por interacción. El almacenamiento en caché del lado del cliente se utiliza para mitigar este problema.

Almacenamiento en caché

Las aplicaciones cliente pueden almacenar en caché las respuestas del servidor y reutilizarlas para solicitudes posteriores a fin de mejorar la eficiencia de la red y el rendimiento percibido por el usuario.

Almacenamiento en caché en un Red de distribución de contenido (CDN), la memoria del dispositivo o en un almacenamiento en caché del navegador reduce significativamente el número de interacciones cliente-servidor.

Tenga en cuenta que el almacenamiento en caché puede disminuir la confiabilidad ya que los datos almacenados en caché pueden diferir de los datos obtenidos al enviar una nueva solicitud al servidor.

Interfaz uniforme

La interfaz uniforme es una restricción fundamental del estilo arquitectónico REST.

Las respuestas del servidor no otorgan a los clientes acceso a un recurso, sino una representación de recursos desacoplada. Por ejemplo, el cliente no recibe una base de datos del servidor sino un documento web JSON, HTML o XML que representa los registros de la base de datos en el formato descrito en la solicitud del cliente. 

La interfaz uniforme se basa en cuatro principios:

• Identificación de recursos - Para simplificar y mejorar la visibilidad de las interacciones, cada recurso dentro de un sistema debe tener un URI único. Las representaciones de recursos deben cumplir con pautas específicas, incluidos formatos de datos, convenciones de nomenclatura y formatos de enlaces.
• Manipulación de recursos a través de representaciones – La representación del recurso debe contener suficientes datos para que el cliente pueda modificar o eliminar el estado del recurso. Los recursos deben ser accesibles y modificables a través de un enfoque común, como un método HTTP (es decir, POST, GET).
• Mensajes autodescriptivos - Cada mensaje debe ser autodescriptivo e incluir suficiente información para describir cómo procesar el mensaje. Los clientes pueden obtener los datos necesarios comprobando la semántica sin conocer la estructura de datos específica de la aplicación.
• Hipermedia como motor del estado de la aplicación (HATEOAS): los clientes envían un mensaje que incluye un encabezado, un cuerpo y parámetros de cadena de consulta al URI del recurso. Los servicios responden mediante encabezados de respuesta, contenido del cuerpo y códigos de respuesta. Además del proceso descrito, el principio HATEOS establece que (cuando sea necesario) el hipertexto del cuerpo (o encabezado) devuelto debe contener hipervínculos que el cliente pueda usar para descubrir dinámicamente todos los recursos disponibles que necesita.

Sistema de capas

La implementación de servicios web, almacenamiento de datos y lógica de seguridad en capas separadas y jerárquicas permite a los desarrolladores imponer límites sobre cómo interactúan estos componentes.

Restringir el “conocimiento” de un recurso da como resultado un sistema menos complejo con capas independientes y controlables.

Un sistema en capas es esencial para hacer cumplir las políticas de seguridad en la arquitectura web moderna. También mejora la escalabilidad y permite que los recursos llamen a varios servidores intermediarios al generar una respuesta del cliente.

Los mensajes entre el cliente y el servidor de destino siempre deben formatearse y procesarse de la misma manera, independientemente de las capas entre ellos. Las capas adicionales no deberían afectar las interacciones cliente-servidor.

Código bajo demanda (opcional)

La restricción REST Code on Demand es opcional. REST permite que las aplicaciones cliente amplíen la funcionalidad al descargar y ejecutar widgets o scripts. Por ejemplo, un comerciante puede usar el widget de un procesador de pagos para facilitar la autenticación sólida del cliente.

Sin embargo, el código bajo demanda también reduce la visibilidad. Se deja en manos del desarrollador aplicar o ignorar esta restricción según el caso de uso previsto y el contexto.

¿Cómo funciona la API REST?

Los proveedores de API REST suelen proporcionar documentación exhaustiva que enumera Puntos finales API y explica cómo estructurar una llamada a la API.

La URL del punto final representa la ubicación de recursos que los usuarios de la API utilizan para enviar solicitudes e interactuar con los recursos.

Aunque REST admite muchos protocolos de comunicación, el protocolo HTTP se ha convertido en un estándar para la mayoría de las aplicaciones modernas.

Las solicitudes HTTP del cliente tienen 5 elementos separados:

• Verb − Define el método de solicitud HTTP (es decir, GET, POST, DELETE, PUT, PATCH).
• URI (Uniform Resource Identifier) − La URI identifica el recurso en el servidor.
• Versión HTTP − Especifica la versión de HTTP (por ejemplo, v1 or v2).
• Solicitar encabezados − Un encabezado HTTP es un par de nombre y valor separados por dos puntos (:). Los encabezados contienen más información sobre el recurso o el cliente que envía la solicitud. Esto puede incluir el tipo de navegador, los formatos admitidos por el cliente, la autorización, los métodos de autenticación, etc.
• Cuerpo de solicitud − El contenido del mensaje de solicitud en el formato de datos especificado.

Las respuestas HTTP constan de 4 elementos:

• Código de respuesta/Estado del recurso − El código de respuesta indica el estado del recurso del servidor solicitado. Por ejemplo, respuesta 200 implica que la solicitud fue exitosa, mientras que la 415 El código de error sugiere que el formato de datos en el mensaje de solicitud no es compatible.
• Versión HTTP − Especifica la versión de HTTP.
• Encabezados de respuesta − Los metadatos de Respuesta HTTP. Puede indicar si un mensaje es cacheable o no cacheable, tipo de servidor, datos de respuesta, tipo de contenido, etc.
• Cuerpo de respuesta − El contenido del mensaje de respuesta (representación de recursos).

Los métodos de solicitud HTTP, también llamados verbos HTTP, permiten a los clientes especificar el tipo de acción que desean realizar en un recurso determinado. Cada método desencadena un proceso diferente, pero se pueden agrupar en función de características comunes.

Segura Los métodos HTTP, como GET o HEAD, solicitan operaciones de solo lectura que no modifican los recursos del servidor. Los verbos que permiten a los clientes enviar la misma solicitud muchas veces sin cambiar el estado de los recursos del servidor se denominan idempotente verbos

Los métodos RESTful HTTP utilizados con frecuencia incluyen:

MÉTODO HTTP (VERBO)	DESCRIPCIÓN	SEGURA	IDEMPOTENTE
	El verbo GET se usa para recuperar un recurso de un servidor. Los datos solo se leen y no se modifican.	Sí	Sí
CABEZA	Al igual que GET, HEAD recupera un recurso. Sin embargo, la respuesta solo contiene el estado del recurso y el encabezado y no devuelve un cuerpo. Se utiliza para comprobar qué podría devolver potencialmente una solicitud GET.	Sí	Sí
PUBLICAR	Se utiliza para enviar una solicitud para crear o actualizar un recurso de servidor. Las solicitudes POST no se almacenan en caché y no permanecen en el historial del navegador.	No	No
PUT	El verbo PUT reemplaza la representación existente del recurso de destino con contenido recién cargado. Enviar la misma solicitud PUT varias veces produce el mismo resultado.	No	Sí
BORRAR	Elimina el recurso especificado.	No	Sí
PARCHE	Realiza cambios parciales en un recurso existente.	No	No
CAMPUS	El verbo OPCIONES ayuda a los clientes a saber qué opciones de comunicación están asociadas con un recurso.	Sí	Sí
TRACE	Realiza una prueba de bucle invertido de mensajes a lo largo de la ruta al recurso de destino.	Sí	Sí

Las API REST admiten múltiples formatos para intercambiar y almacenar datos como JSON, XML, HTML, Ñame, etc. Esta amplia gama de diferentes formatos de datos hace que REST sea un estilo arquitectónico popular para crear API públicas.

¿Para qué se utiliza la API REST?

El estilo arquitectónico REST permite que las soluciones de software se comuniquen independientemente de su tamaño y complejidad. Admite varios protocolos de transferencia, siendo HTTP el más común, y múltiples formatos de datos que son legibles por máquina y por humanos.

La capacidad de implementar y escalar componentes de forma independiente hace que las API RESTful sean ideales para sistemas que atienden a una gran cantidad de clientes diversos, como servidores web y aplicaciones web.

Con la capacidad de hacer cumplir la seguridad, disminuir la latencia y encapsular sistemas heredados, las API REST se pueden aplicar a casi cualquier caso de uso. Son especialmente adecuados para:

• Automatización de la entrega y uso de servicios financieros (Fintech).
• Aplicaciones web progresivas (PWA).
• Procesamiento de pagos y autenticación del cliente.
• Plataformas de redes sociales.
• Comercio sin cabeza.
• Herramientas de gestión de proyectos.
• Plataformas de gestión de relaciones con los clientes (CRM).
• La computación en la nube y servicios en la nube.

Ejemplos de API REST

Algunas de las marcas más grandes del mundo usan API RESTful para exponer sus servicios a otras empresas y usuarios finales. Los ejemplos de alto perfil incluyen:

Salesforce

La API REST de Salesforce permite a los usuarios crear, analizar y modificar datos de clientes sin acceder a la interfaz de usuario de Salesforce.

Las empresas pueden integrar los servicios de Salesforce en sus aplicaciones y optimizar los procesos comerciales mediante el envío de solicitudes HTTP a los extremos de la API de Salesforce.

Los diferentes puntos finales otorgan a las aplicaciones cliente acceso y permiso para operar en los resultados de consultas, metadatos, registros y otros recursos.

El proceso de integración está respaldado por una documentación completa y fácil de usar. La API REST puede integrarse con otras API de Salesforce y utilizarse para desarrollar IU personalizadas para generar vistas de lista, acciones y listas de selección dependientes.

Twitter

Twitter utiliza una serie de puntos finales de API para exponer una multitud de servicios diferentes. Las empresas pueden usar estos puntos finales para recuperar mediante programación los datos que los usuarios publican en Twitter y los datos que Twitter agrega sobre sus usuarios.

---

Nota: La API web basada en HTTP de Twitter no se adhiere estrictamente a las seis restricciones REST.

---

La cantidad de puntos de conexión y funciones disponibles en la API de Twitter puede dificultar la determinación de qué punto de conexión de la API es relevante para un caso de uso específico. La API de Twitter permite a las organizaciones: 

• Realice un seguimiento y reaccione ante publicaciones, conversaciones y percepciones en torno a una empresa, marca o servicio.
• Recupera Tweets, Mensajes Directos y otras actividades relacionadas con una cuenta.
• Resuelva problemas comunicándose con los clientes en tiempo real.
• Realice un seguimiento del retorno de la inversión (ROI) en campañas de marketing dirigidas.
• Cura y recomienda contenido.
• Analice las tendencias, las preferencias de los clientes y las estrategias de marketing de la competencia.
• Filtre, recupere y analice Tweets relevantes.

Las organizaciones pueden usar grandes cantidades de datos en tiempo real para crear aplicaciones para evaluar e incluso reaccionar a los Tweets relacionados con temas específicos.

CCBill

La API de transacciones RESTful de CCBill permite a los comerciantes acceder y utilizar la plataforma de pago de CCBill y cobrar a los clientes con un token de pago. Los comerciantes pueden desarrollar flujos de compra personalizados sin utilizar los formularios de pago alojados de CCBill.

CCBill proporciona documentación API detallada que enumera todos los puntos finales, recursos y ejemplos de consultas relevantes de la API.

Para agilizar el proceso de implementación, CCBill desarrolló un widget avanzado para automatizar las solicitudes de tokens de pago. CCBill Advanced Widget también permite a los comerciantes integrarse con el proveedor 3DS de CCBill e incorporar autenticación de cliente fuerte en sus transacciones.

Trello

Trello es una herramienta de gestión de proyectos que proporciona una API web RESTful simple. Cada tipo de recurso API (p. ej., Tablero, Lista, Tarjeta, Miembro, Acción) tiene un URI único con el que las aplicaciones cliente pueden interactuar.

Trello maneja el proceso de autenticación y autorización para que las aplicaciones de los clientes no tengan que almacenar nombres de usuario o contraseñas. Las aplicaciones delegan temporalmente la autenticación de usuario a Trello a través de un Clave API. El control, junto con un token de API, se devuelve a la aplicación del usuario una vez que el usuario inicia sesión correctamente.

Prácticas recomendadas de la API REST

Diseñar una API basada en restricciones arquitectónicas REST es un desafío. Aplique las siguientes prácticas para asegurarse de que una API sea fácil de ver, leer y consumir:

1. Use el formato de datos JSON para solicitudes y respuestas - La mayoría de los entornos de programación tienen la capacidad de analizar y generar JSON. Su estructura lingüística también permite que los humanos lean y entiendan la sintaxis JSON fácilmente.
2. Aplicar el control de versiones estándar de la API - Si el servicio de la API tiene varias versiones, asegúrese de que el número de versión esté incluido en el URI de la API REST. Esto agiliza el proceso de desarrollo y garantiza que los cambios no rompan las aplicaciones del cliente.
3. No use verbos en rutas de puntos finales - Dado que los métodos de solicitud HTTP ya contienen verbos, insertarlos en las rutas de los puntos finales es ineficiente. Solo use sustantivos en los URI de punto final.
4. Use códigos y mensajes de error de estado HTTP estándar - Usar códigos de error HTTP estándar como el 503 error de servicio no disponible o de Código de error 403 ayuda a los usuarios de API a comprender instantáneamente qué tipo de error ocurrió. El mensaje de error debe contener suficiente información para facilitar la solución de problemas, pero también para evitar que posibles atacantes exploten el contenido del mensaje de error.

5. Diseñe terminales consistentes y lógicos - Defina y agrupe puntos finales para reflejar la estructura lógica y la jerarquía de los objetos de la base de datos. Sin embargo, evite revelar la estructura exacta de la base de datos, ya que los atacantes pueden explotar esta información.
6. Emplear buenas prácticas de seguridad. - Una brecha de seguridad puede causar una pérdida irreparable de ingresos y reputación. Las organizaciones que exponen sus servicios mediante API deben desarrollar procedimientos de seguridad estrictos, capacitar al personal e implementar soluciones técnicas avanzadas:
   • conseguir una Certificado SSL.
   • Evite el acceso desde direcciones IP y dominios desconocidos.
   • Bloquee cargas útiles inusualmente grandes.
   • Registre todas las solicitudes e investigue minuciosamente las solicitudes fallidas.
   • Defina estrictamente las funciones de los usuarios y restrinja el acceso de los usuarios de acuerdo con los principios de privilegio mínimo.
7. Mantenga la carga de la base de datos y los tiempos de respuesta bajo control - Las bases de datos de la API crecen con el tiempo, lo que aumenta el tiempo necesario para buscar y recuperar datos. Utilice la paginación, la clasificación y los puntos finales filtrados para agilizar las búsquedas y la recuperación de datos de las colecciones de API REST.
8. Permitir el almacenamiento en caché del lado del cliente - El almacenamiento en caché reduce la latencia, el ancho de banda y las cargas del servidor. Agrega un <strong><em>Cache-Control</em></strong> directiva a los encabezados de respuesta para permitir explícitamente el almacenamiento en caché del lado del cliente.
9. Asegúrese de que la documentación de la API sea completa y precisa - La documentación de API es el recurso principal de un desarrollador para implementar una solución de API de terceros. La documentación debe transmitir:
   • Los puntos finales de la API relevantes.
   • Instrucciones sobre cómo estructurar una solicitud de API (incluidos varios métodos HTTP y ejemplos de formatos de datos aceptables).
   • Ejemplos de respuestas esperadas.
   • Lista de posibles códigos y mensajes de error.

La aplicación de estas recomendaciones permite a los usuarios de API consumir su solución RESTful API de manera fácil y segura.

Conclusión

Conoce cómo funcionan los sistemas RESTful, sus limitaciones arquitectónicas y los tipos de proyectos para los que son más adecuados.

Los nuevos desarrolladores de API REST deben trabajar duro para lograr una implementación que funcione. El desarrollo de API es un enfoque basado en las mejores prácticas, y artículos como este son el único primer paso para crear un diseño de API limpio y nítido.