¿Qué es una API REST?

En la informática moderna, las API se han convertido en la forma de interacción más común entre los programas y los dispositivos. Una API consiste en un conjunto de reglas que describen cómo los programas pueden conectarse y comunicarse entre sí. Como su nombre indica, una API REST transfiere, en cada solicitud, el estado de cualquier transacción, ofreciendo una serie de ventajas en términos de diseño, rendimiento y recursos frente a otros enfoques. REST, con más de dos décadas de desarrollo en su historia, es un enfoque muy común en las arquitecturas distribuidas y basadas en servicios.

Los recursos son un concepto fundamental para las API REST. Estos recursos consisten en un objeto con un tipo, datos asociados, relaciones con otros recursos y un conjunto de métodos que operan en él. Este concepto es comparable a los objetos en programación, aunque solo se definen unos cuantos métodos estándar, como HTTP GET, POST, PUT y DELETE. Los recursos pueden existir de forma independiente o agruparse en colecciones que también se consideran recursos.

En la informática moderna, un modelo común, también fundamental para las API REST, es el cliente-servidor, donde un cliente que necesita un recurso identifica y se comunica con el servidor que puede proporcionarlo. Prácticamente todo el tráfico cloud se gestiona de esta manera, ya que ofrece una gran flexibilidad al permitir que múltiples clientes accedan a múltiples servidores. Este principio también funciona bien en las llamadas arquitecturas «sin servidor», en las que un intermediario sustituye a un servidor conocido por el cliente.

La arquitectura API REST empezó a desarrollarse en 1993, cuando surgieron los primeros sitios web de uso general.

La rápida expansión de internet dio lugar a diferentes propuestas de extensiones del protocolo de transferencia de hipertexto (HTTP) original. El Consorcio de la World Wide Web (W3C) y el Grupo de Trabajo de Ingeniería de Internet (IETF) comenzaron a trabajar en la evaluación y formalización de nuevas versiones de HTTP, el protocolo de transferencia de hipertexto (HTML) y los estándares URI.

Tras seis años trabajando en la estandarización de HTTP y URI, el investigador Roy Fielding definió REST en 2000, estableciendo el estilo arquitectónico para verificar el desarrollo futuro de los protocolos web e identificar aquellas extensiones que no se ajustaban bien a los objetivos de comportamiento y rendimiento de internet.

Posteriormente, los conceptos REST han sabido adaptarse muy bien al desarrollo de la informática conectada. Desde 2015, la iniciativa OpenAPI, bajo el patrocinio de la Fundación Linux y en colaboración con otros miembros como Google, IBM, Microsoft o PayPal, ha creado la especificación OpenAPI basada en reglas RESTful, que publica archivos de interfaz legibles por máquina para describir, producir, consumir y visualizar servicios web RESTful.

Las aplicaciones implementadas basadas en archivos de interfaz OpenAPI pueden generar automáticamente la documentación de los métodos, los parámetros y los modelos. Además de ofrecer un enfoque industrial para la estandarización de cabeceras, códigos, descripciones de recursos e innovaciones futuras, la iniciativa OpenAPI proporciona herramientas, materiales de referencia y mejores prácticas para los usuarios. Estos recursos resultan especialmente importantes a la hora de crear, verificar y utilizar correctamente la autenticación y la seguridad de los datos con un enfoque RESTful, en el que la iniciativa OpenAI cobra especial importancia.

1. Interfaz uniforme

Todas las solicitudes realizadas a través de una API REST deben respetar las normas de formato de dicha API. Independientemente del cliente que realice la solicitud, cada elemento de información debe colocarse del mismo modo que lo colocaría cualquier otro cliente. Un ejemplo es la URL (Uniform Resource Locator) que se utiliza para identificar recursos a través de HTTP, que es un ejemplo de identificador uniforme de recursos (URI) que puede tener un alcance mayor.

2. Separación cliente-servidor

Las API REST requieren que las aplicaciones cliente y servidor sean totalmente independientes entre sí. El cliente solo tiene que conocer el nombre completo del recurso que quiere utilizar en el espacio virtual permitido por la API. El único conocimiento que el cliente y el servidor tienen del otro es la información que se intercambia a través de las transacciones API.

3. Sin estado

Cada solicitud del cliente debe contener toda la información necesaria para procesarla y, una vez recibida, el servidor no necesita conservar ninguna información sobre dicha solicitud. Así pues, no existe el concepto de sesión en el diseño de la API REST y el servidor no tiene ningún estado («stateless») con respecto a un cliente en particular.

4. Puesta en caché

A diferencia de la ausencia de estado por cliente del servidor, los recursos deben poder almacenarse en caché en uno o más puntos en el cliente y el servidor, o entre estos últimos. En el caso del servidor, si se ha servido un recurso determinado y es probable que este vuelva a solicitarse en un período de tiempo determinado, deberá almacenarse en caché para obtener una respuesta posterior más rápida. El cliente debe adoptar una decisión similar con respecto a los recursos recibidos. Así pues, el servidor deberá indicar a través de la API si un recurso puede almacenarse localmente en caché en el cliente de forma segura, incluyendo la vida útil de los datos, cuando sea necesario. El diseño de la caché, aunque no forma parte de las especificaciones de las API RESTful, es fundamental para el rendimiento, por lo que los diseñadores de API deben conocer cómo aplicar estos principios en la práctica.

5. Arquitectura de sistemas superpuestos

Una de las consecuencias de la separación entre cliente y servidor, el diseño sin estado y la capacidad de almacenamiento en caché es que el cliente no puede saber si se está comunicando directamente con un servidor que contiene un recurso determinado o con un intermediario, como un agente de servicios, un load balancer, un sistema de entrega de contenidos u otros subsistemas más cercanos al cliente que el propio servidor. Esto proporciona a los diseñadores de sistemas e infraestructuras una mayor flexibilidad para maximizar la eficacia y la fiabilidad de la satisfacción de las solicitudes en toda la infraestructura mundial por cable e inalámbrica. Este principio pone de relieve la funcionalidad del «edge computing».

6. Código bajo demanda

Aunque las API REST pueden servir (y suelen servir) solamente datos para el consumo del cliente, cada vez es más común que el código se entregue para ejecutarse en el cliente, como objetos Java o aplicaciones web JavaScript. En ese caso, el código solo puede ejecutarse previa petición del cliente.

Las API REST pueden tratar prácticamente cualquier solicitud de acceso, formato de datos, control de recursos o mensajes de estado, pero el diseño sin estado requiere que cada solicitud contenga las autenticaciones necesarias para comprobar la solicitud, la definición precisa del recurso solicitado y la acción concreta requerida.

Por ejemplo, una API de sistema de archivos que no sea RESTful podría responder a una solicitud de lectura de un archivo devolviendo un identificador de archivo, es decir, un pequeño token asignado a una sesión para que el cliente pueda realizar lecturas repetidas utilizando solo como referencia ese identificador. La API REST, por su parte, tendría que enviar la autorización del cliente con cada solicitud, pero también el identificador de recurso exacto completo junto con la ubicación exacta en el archivo de los datos que se van a leer. En este caso, el cliente debe realizar el seguimiento correspondiente.

Las API REST transmiten toda esta información mediante una combinación de cabeceras y campos de parámetros, y pueden intercambiar los datos reales en cualquier formato. Un estándar muy común es JSON, el formato de notación de objetos de JavaScript, que, pese a su nombre, es legible tanto por personas como por máquinas utilizando cualquiera de los lenguajes de programación más populares.

El diseño de la API REST debe tener en cuenta la eficiencia, especialmente cuando se gestionan grandes transferencias de datos o flujos en los que el tiempo es un factor crítico, pero también a la inversa, cuando se manejan pequeñas cantidades de datos procedentes de fuentes limitadas en recursos, como los sistemas IoT.

La API de OVHcloud es un servicio web que permite a los clientes de OVHcloud adquirir, gestionar, actualizar y configurar los productos de OVHcloud sin necesidad de utilizar la interfaz gráfica de cliente. Este servicio está basado en la última API RESTful, capaz de gestionar prácticamente los productos de todos los universos de OVHcloud. En concreto, la API de OVHcloud está diseñada para ser simple y fácil de utilizar, y los fragmentos de código se proporcionan en una gran variedad de lenguajes.

Asimismo, esta API también permite acceder a la última versión del área de cliente (V6) y es compatible con todas las nuevas versiones de productos e interfaces. La consola de exploración permite recorrer la API para conocer todas las funciones disponibles con los productos de OVHcloud, incluso para aquellos usuarios que no están registrados como desarrolladores. También es posible seleccionar un producto y navegar por la API dedicada para descubrir acciones relacionadas.

El uso de la API RESTful de OVHcloud permite un desarrollo rápido y ligero de scripts para funciones personalizadas, mayor automatización, múltiples tareas simultáneas y la creación de herramientas de despliegue y gestión IaaS y PaaS. Existe soporte para lenguajes explícitos disponible para C, C++, C#, Java, Perl, PHP, Python o Ruby, entre otros.