Una API REST es un tipo de interfaz de programación de aplicaciones (API) que cumple con la transferencia de estado representacional (REST) de representación de datos y comunicación entre dos sistemas (un cliente y un servidor) a través de una red como Internet. Las API REST admiten el intercambio de información entre aplicaciones internas y de terceros, y permiten a las empresas integrar múltiples puntos finales en su ecosistema de aplicaciones.
Nota: En sentido estricto, REST se refiere al modelo y no es un adjetivo que designe una API que se adhiera a él, para lo cual el término adecuado es API RESTful. Sin embargo, API REST es el uso más común y, en consecuencia, se utiliza en este artículo.
REST, que como 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 proporciona flexibilidad a los desarrolladores, lo que lo hace ideal para conectar aplicaciones en arquitecturas de microservicios.
REST define seis restricciones que las aplicaciones y API deben cumplir para ser consideradas RESTful:
Puede obtener más información sobre estas condiciones en Wikipedia.
Una interfaz uniforme simplifica la arquitectura general del sistema y mejora la visibilidad de las interacciones. También tiene requisitos específicos para garantizar que la información se transfiere de forma estándar.
Cuatro restricciones permiten que una interfaz REST sea uniforme:
Una arquitectura cliente-servidor se compone de clientes, servidores y recursos. Separar la interfaz de usuario, controlada por el cliente, del almacenamiento de datos, gestionado por el servidor, permite que ambos componentes evolucionen de forma autónoma. Esto también simplifica la portabilidad de la interfaz de usuario a través de múltiples plataformas y mejora la escalabilidad del servidor.
En Internet, la interacción cliente-servidor tiene lugar a través de HTTP.
En la comunicación cliente-servidor, la ausencia de estado significa que el servidor no almacena ninguna información sobre el cliente o la sesión establecida con él. La representación por parte del cliente de la información relacionada con la sesión en cada mensaje debe permitir al servidor entenderla de forma aislada, sin ningún contexto de mensajes anteriores. Esto reduce la carga del servidor, mejorando el rendimiento de las aplicaciones de gran volumen.
Los clientes no necesitan saber (y normalmente no pueden saberlo) si están conectados directamente al servidor o a un intermediario, como un proxy inverso o un equilibrador 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.
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 los datos a los usuarios finales. El servidor debe indicar si una respuesta es almacenable en caché o no, y esto último garantiza que las respuestas a posteriores solicitudes del usuario final sean correctas y estén actualizadas (no potencialmente «obsoletas»). Dado que los clientes acceden a un recurso por su URL, que es un identificador único, el cliente puede determinar qué almacenar en caché a nivel de recurso.
Código bajo demanda significa que el servidor puede enviar código ejecutable al cliente para ampliar o personalizar temporalmente su funcionalidad, eliminando la necesidad de que el cliente implemente esa funcionalidad por sí mismo. La utilización de código bajo demanda es opcional.
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:
Una API REST consta de un conjunto de recursos interconectados (o su modelo de recursos) que son accesibles en URI únicos. Un cliente puede lograr una funcionalidad flexible mediante la vinculación a recursos relacionados y URI dentro de la respuesta. En general, una solicitud a una API REST se realiza mediante una petición HTTP GET, y los servidores suelen devolver sus respuestas en formato JSON.
Los siguientes métodos de petición HTTP se utilizan para actuar sobre los recursos de la forma indicada:
En los estilos arquitectónicos REST, los identificadores de recursos designan de forma única cada recurso que participa en las interacciones cliente-servidor.
Un «tipo de medio», o representación de formato de datos, define cómo debe procesarse un recurso. En las API REST, los tipos de medio suelen basarse en JSON y son considerados hipermedios (a menudo conocidos como hipertexto, aunque ligeramente diferentes). El hipermedio se refiere a cualquier contenido que contenga enlaces a otros recursos o medios. El concepto de hipermedios 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 REST, debe utilizar hipermedios. Sin embargo, muchos diseñadores de API de hoy en día suelen llamar a sus API «REST[ful]» como palabra de moda aunque no utilicen hipermedios/hipertexto.
Las representaciones de recursos pretenden ser autodescriptivas, lo que significa que la API se hace entender dentro de su propio contexto. Con las representaciones autodescriptivas, el cliente no necesita saber a qué categoría pertenece un recurso y, en su lugar, actúa en función del tipo de medio asociado al recurso.
Hoy en día, la mayoría de las empresas utilizan API desarrolladas tanto internamente como de terceros para facilitar la comunicación entre aplicaciones que proporcionan funcionalidades básicas, innovadoras y críticas. La mayoría de estas API son API REST, ya que los estándares de comunicación definidos por REST permiten un intercambio de información seguro, eficiente y fiable. Además, las API REST pueden operar sobre diversos protocolos.
Las API REST también son seguras porque el servicio web RESTful autentica las solicitudes antes de enviar una respuesta. Para verificar las identidades de los usuarios, las API REST emplean autenticación HTTP (tanto básica como de token de portador), claves API y OAuth para el acceso de inicio de sesión.
Otras ventajas de las API REST son:
Aunque REST sigue siendo la arquitectura más popular para conectar aplicaciones cliente-servidor, GraphQL (desarrollada por Facebook en 2012 y lanzada como código abierto en 2015) se diseñó como una alternativa a REST. Las API GraphQL son más eficientes que las REST, ya que permiten solicitar todos los datos necesarios en una sola petición de manera estandarizada. Sin embargo, hay áreas en las que REST sigue destacando. GraphQL presenta una curva de aprendizaje más pronunciada y es menos optimizable en términos de almacenamiento en caché que REST. Además, las aplicaciones suelen estar orientadas a recursos y no requieren un lenguaje de consulta como el que ofrece GraphQL. Dicho esto, cada modelo tiene sus pros y sus contras y las organizaciones pueden optar por utilizar ambos.
La flexibilidad de las API REST es, sin duda, una ventaja. Sin embargo, un exceso de flexibilidad puede dar lugar a una API lenta o defectuosa, lo que lleva a muchos desarrolladores a optar por la especificación OpenAPI para publicar, gestionar y documentar sus API.
API Connectivity Manager, que forma parte de F5 NGINX Management Suite, es compatible con la especificación OpenAPI para API REST. API Connectivity Manager se diseñó teniendo como núcleo la experiencia del desarrollador de API. Es una solución de gestión de API ligera y nativa de la nube con una integración perfecta para publicar API en el portal del desarrollador y la puerta de enlace de API.
Inicie una prueba gratuita de 30 días de NGINX Management Suite, que incluye API Connectivity Manager e Instance Manager.