Una API REST es un tipo de interfaz de programación de aplicação (API) que cumple con el modelo de transferencia de estado representacional (REST) de representación y comunicación de datos 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 aplicações internas y de terceros, y permiten a las empresas integrar múltiples puntos finales en su ecosistema de aplicação .
Nota: En sentido estricto, REST se refiere al modelo y no es un adjetivo que designe una API que se adhiere a él, para lo cual el término correcto es API RESTful . Sin embargo, API REST es el uso más común y, por lo tanto, se utiliza en este artículo.
REST, que como se mencionó significa transferencia de estado representacional , es un estilo arquitectónico creado por el científico informático Roy Fielding en 2000. REST proporciona flexibilidad a los desarrolladores, lo que lo hace ideal para conectar aplicações 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 restricciones 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 se realiza 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 ) a los que se puede acceder mediante URI únicos. Un cliente puede lograr una funcionalidad flexible al vincularse con recursos y URI relacionados dentro de la respuesta. En general, una solicitud a una API REST se envía en forma de una solicitud HTTP GET; los servidores a menudo forman sus respuestas como 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 del formato de datos, define cómo se debe procesar un recurso. En las API REST, todos los tipos de medios se basan en JSON y son hipermedia (a veces conocidos como hipertexto , aunque son ligeramente diferentes). Hipermedia es cualquier pieza de contenido con enlaces a otros medios. Hipermedia como motor del estado de la aplicação (HATEOAS) es lo que hace que la arquitectura REST sea única.
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 una palabra de moda, aunque no utilicen hipermedia/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 Bearer Token ), claves API y OAuth para el acceso de inicio de sesión.
Otras ventajas de las API REST son:
Si bien REST sigue siendo la arquitectura más popular para conectar aplicações cliente y servidor, GraphQL (desarrollado por Facebook en 2012 y de código abierto en 2015) fue diseñado como una alternativa a REST. Las API GraphQL son más eficientes que las API REST porque todos los datos necesarios se solicitan en una sola solicitud y en un formato estandarizado, pero aún hay algunas áreas en las que REST destaca. GraphQL requiere una curva de aprendizaje pronunciada y es mucho menos almacenable en caché que REST. Además, las aplicações a menudo están impulsadas por recursos y no requieren un lenguaje de consulta como 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 ciertamente una ventaja. Pero demasiada flexibilidad también puede llevar al diseño de una API potencialmente lenta o rota, por lo que muchos desarrolladores optan por publicar, administrar y generar documentación de API utilizando la Especificación OpenAPI .
API Connectivity Manager , parte de F5 NGINX Management Suite , admite la especificación OpenAPI para API REST. API Connectivity Manager fue diseñado teniendo como base la experiencia del desarrollador de API. Es una solución de gestión de API liviana y nativa de la nube con una integración perfecta para publicar API en el portal para desarrolladores y la puerta de enlace de API.
Comience una prueba gratuita de 30 días de NGINX Management Suite , que incluye API Connectivity Manager y Instance Manager .