¿Qué es una API REST?

Una API REST es un tipo de interfaz de programación de aplicaciones (API) que cumple con el modelo de transferencia de estado representacional (REST) para la representación de datos y la comunicación entre dos sistemas (un cliente y un servidor) a través de una red como Internet. Las API REST permiten el intercambio de información entre aplicaciones internas y de terceros, y permiten a las empresas integrar múltiples puntos de conexión en su ecosistema de aplicaciones.

Nota: En sentido estricto, REST hace referencia al modelo y no es un adjetivo que designe una API que se ajuste a él, para la cual el término correcto es API RESTful. Sin embargo, API REST es el término más habitual y, por tanto, el que se utiliza en este artículo.

¿Qué es REST?

REST, que, como ya se ha mencionado, significa transferencia de estado representacional, es un estilo arquitectónico creado por el informático Roy Fielding en el año 2000. REST ofrece flexibilidad a los desarrolladores, lo que lo hace ideal para conectar aplicaciones en arquitecturas de microservicios.

REST define seis restricciones que las aplicaciones y las API deben cumplir para considerarse RESTful:

• Interfaz uniforme
• Arquitectura cliente-servidor
• Ausencia de estado
• Sistema por capas
• Capacidad de almacenamiento en caché
• Código bajo demanda

Puedes obtener más información sobre estas restricciones en Wikipedia.

Interfaz uniforme

Una interfaz uniforme simplifica la arquitectura general del sistema y mejora la visibilidad de las interacciones. También establece requisitos específicos para garantizar que la información se transfiera de forma estandarizada.

Cuatro restricciones permiten que una interfaz REST sea uniforme:

• Cada recurso tiene un identificador único, como un URI, y la representación del recurso en un mensaje es independiente de la representación interna del servidor
• La representación del recurso incluye información suficiente para que el cliente pueda modificar o eliminar el estado de un recurso
• Cada mensaje incluye suficiente información para describir cómo procesarlo
• El servidor utiliza hipervínculos para informar a los clientes sobre los recursos disponibles, lo que elimina la necesidad de que conozcan el funcionamiento interno del servidor

Cliente-servidor

Una arquitectura cliente-servidor se compone de clientes, servidores y recursos. Separar la interfaz de usuario (controlada por el cliente) del almacenamiento de datos (controlado por el servidor) permite que los componentes del cliente y del servidor evolucionen de forma autónoma. También facilita la portabilidad de la interfaz de usuario del cliente entre distintas plataformas y la escalabilidad del servidor.

En Internet, la interacción entre cliente y servidor se realiza mediante HTTP.

Ausencia de estado

En la comunicación cliente-servidor, la ausencia de estado significa que el servidor no almacena información sobre el cliente ni sobre la sesión establecida con él. La información relacionada con la sesión que el cliente incluye en cada mensaje debe permitir que el servidor lo interprete de forma aislada, sin necesidad del contexto de mensajes anteriores. Esto reduce la carga del servidor y mejora el rendimiento de las aplicaciones con un gran volumen de tráfico.

Sistema por capas

Los clientes no necesitan saber (y, por lo general, no pueden determinar) si están conectados directamente al servidor o a un intermediario, como un proxy inverso o un balanceador de carga. Los servidores intermediarios ayudan a mejorar la escalabilidad y pueden utilizarse para gestionar la seguridad, de modo que los servidores solo sean responsables de la lógica de negocio.

Capacidad de almacenamiento en caché

Los clientes HTTP y los intermediarios pueden almacenar en caché las respuestas del servidor para reducir su carga y aumentar la velocidad de entrega de datos a los usuarios finales. El servidor debe indicar si una respuesta se puede almacenar en caché o no; en este último caso, se garantiza que las respuestas a las solicitudes posteriores de los usuarios finales sean correctas y estén actualizadas (y no puedan estar «obsoletas»). Dado que los clientes acceden a un recurso mediante su URL, que es un identificador único, pueden determinar qué almacenar en caché en el ámbito de cada recurso.

Código bajo demanda

El código bajo demanda permite que el servidor envíe código ejecutable para ampliar o personalizar temporalmente la funcionalidad del cliente, evitando así que este tenga que implementarla por sí mismo. La restricción de código bajo demanda es opcional.

¿Qué es un recurso?

La representación o abstracción de datos más importante en REST es un recurso. Un recurso REST puede ser cualquier tipo de información abstraída, desde un documento digital hasta un objeto no digital. El estado del recurso en un momento dado se denomina representación del recurso.

La representación de un recurso consta de tres partes:

• Datos
• Metadatos
• Enlaces hipermedia

Una API REST consta de un conjunto de recursos interconectados (o su modelo de recursos ) a los que se puede acceder mediante URI únicos. Un cliente puede obtener una funcionalidad flexible mediante enlaces a recursos y URI relacionados incluidos en la respuesta. Por lo general, las solicitudes a una API REST se envían como solicitudes HTTP GET; los servidores suelen devolver las respuestas en formato JSON.

Los siguientes métodos de solicitud HTTP se utilizan para actuar sobre los recursos de la forma indicada:

• GET – Cargar un recurso
• POST – Crear un recurso nuevo
• PUT – Modificar un recurso existente
• DELETE – Eliminar un recurso

Identificador del recurso

En los estilos arquitectónicos REST, los identificadores de recursos designan de forma única cada recurso que interviene en las interacciones entre cliente y servidor.

Hipermedia

Un «tipo de medio», o representación del formato de los datos, define cómo debe procesarse un recurso. En las API REST, todos los tipos de medios se basan en JSON y son hipermedia (a veces conocidos como hipertexto, aunque existe una ligera diferencia). La hipermedia es cualquier contenido que incluye enlaces a otros medios. La hipermedia como motor del estado de la aplicación (HATEOAS) es lo que hace única a la arquitectura REST.

Nota: Según Roy Fielding, para que una API se considere una API REST, debe utilizar hipermedia. Sin embargo, hoy en día muchos diseñadores de API suelen llamar a sus API «REST[ful]» como término de moda, aunque no utilicen hipermedia/hipertexto.

Autodescriptivo

Las representaciones de los recursos pretenden ser autodescriptivas, lo que significa que la API se explica por sí misma dentro de su propio contexto. Con las representaciones autodescriptivas, el cliente no necesita saber a qué categoría pertenece un recurso, sino que actúa en función del tipo de medio asociado al recurso.

Ventajas de las API REST

Hoy en día, la mayoría de las empresas utilizan API desarrolladas internamente y de terceros para la comunicación entre aplicaciones que ofrecen funcionalidades básicas, innovadoras y esenciales. La mayoría de estas API son API REST, ya que los estándares de comunicación específicos que establece REST permiten un intercambio de información seguro, eficiente y fiable. Las API REST también pueden funcionar con cualquier protocolo.

Las API REST también son seguras porque el servicio web RESTful autentica las solicitudes antes de enviar una respuesta. Para verificar la identidad de los usuarios, las API REST emplean autenticación HTTP (tanto básica como mediante token de portador), claves de API y OAuth para el acceso.

Otras ventajas de las API REST son:

• Escalabilidad del sistema – Las API REST pueden escalar de forma eficiente porque REST optimiza las interacciones entre el cliente y el servidor. La restricción de ausencia de estado de REST reduce la carga del servidor, ya que este no tiene que guardar información de solicitudes anteriores ni sobre ellas. Además, la capacidad de almacenamiento en caché reduce el número de interacciones entre el cliente y el servidor que podrían generar cuellos de botella. El resultado son API escalables y de alto rendimiento.
• Flexibilidad para los desarrolladores – Muchas aplicaciones empresariales necesitan comunicarse con API internas o de terceros. Los servicios web RESTful permiten separar el cliente del servidor, lo que posibilita que cada uno evolucione de forma independiente.
• Independencia tecnológica – Las API REST son independientes del lenguaje de programación y del framework con los que se desarrollan las aplicaciones correspondientes. Las aplicaciones cliente y servidor no tienen por qué compartir un mismo lenguaje o framework, y estos pueden cambiar sin afectar al diseño de la API ni al proceso de comunicación.

API REST frente a GraphQL

Aunque REST sigue siendo la arquitectura más popular para conectar aplicaciones cliente y servidor, GraphQL (desarrollado por Facebook en 2012 y publicado como código abierto en 2015) se diseñó como una alternativa a REST. Las API de GraphQL son más eficientes que las API REST porque todos los datos necesarios se solicitan en una única petición y con un formato estandarizado, pero todavía hay algunos aspectos en los que REST destaca. GraphQL presenta una curva de aprendizaje pronunciada y ofrece muchas menos posibilidades de almacenamiento en caché que REST. Además, las aplicaciones suelen basarse en recursos y no requieren un lenguaje de consulta como GraphQL. Dicho esto, cada modelo tiene sus ventajas e inconvenientes, y las organizaciones pueden optar por utilizar ambos.

¿Cómo puede ayudar NGINX?

La flexibilidad de las API REST es, sin duda, una ventaja. Sin embargo, un exceso de flexibilidad también puede dar lugar al diseño de una API potencialmente lenta o defectuosa, por lo que muchos desarrolladores optan por publicar, gestionar y generar documentación de las API mediante la especificación OpenAPI.

API Connectivity Manager, que forma parte de F5 NGINX Management Suite, es compatible con la especificación OpenAPI para las API REST. API Connectivity Manager se diseñó poniendo en el centro la experiencia de los desarrolladores de API. Es una solución ligera y nativa de la nube para la gestión de API, con una integración fluida que permite publicar API en el portal para desarrolladores y en la puerta de enlace de API.

Empieza una prueba gratuita de 30 días de NGINX Management Suite, que incluye API Connectivity Manager e Instance Manager.