¿Qué es la API REST?

Definido por primera vez en 2000 por el informático Dr. Roy Fielding en su tesis doctoral, REST ofrece a los desarrolladores un nivel relativamente alto de flexibilidad, coherencia, escalabilidad y eficiencia. Las API REST proporcionan una forma ligera de crear API web y se utilizan habitualmente para facilitar el intercambio de datos entre aplicaciones, servicios web y bases de datos, y para conectar componentes en arquitecturas de microservicios.

En el nivel más básico, una API es un mecanismo que permite a una aplicación o servicio acceder a un recurso dentro de otra aplicación, servicio o base de datos. La aplicación o servicio que accede a los recursos es el cliente y la aplicación o servicio que contiene el recurso es el servidor.

Algunas API, como SOAP o XML-RPC, imponen un marco estricto para los desarrolladores. Pero los desarrolladores pueden desarrollar API REST utilizando prácticamente cualquier lenguaje de programación y soportando diversos formatos de datos. El único requisito es que se alineen con los siguientes seis principios de diseño REST, también conocidos como restricciones arquitectónicas.

Todas las solicitudes de API para el mismo recurso deben tener el mismo aspecto, sin importar de dónde provenga la solicitud. La API REST debe garantizar que un mismo dato, como el nombre o la dirección de correo electrónico de un usuario, pertenezca a un único identificador uniforme de recursos (URI). Los recursos no deben ser demasiado grandes, pero deben contener toda la información que el cliente pueda necesitar.

En el diseño de una API REST, las aplicaciones cliente y servidor deben ser independientes entre sí. La única información que la aplicación de cliente debe conocer es el URI del recurso solicitado; no puede interactuar con la aplicación de servidor de ninguna otra manera. Del mismo modo, una aplicación de servidor no debe modificar la aplicación de cliente más que pasándole los datos solicitados a través de HTTP.

Las API REST no tienen estado, lo que significa que cada solicitud debe incluir toda la información necesaria para procesarla. En otras palabras, las API REST no requieren ninguna sesión del lado del servidor. Las aplicaciones de servidor no pueden almacenar ningún dato relacionado con una solicitud de cliente.

Cuando sea posible, los recursos deben almacenarse en caché en el lado del cliente o del servidor. Las respuestas del servidor también deben contener información sobre si se permite el almacenamiento en caché para el recurso entregado. El objetivo es mejorar el rendimiento del cliente, al tiempo que aumenta la escalabilidad en el lado del servidor.

En las API REST, las llamadas y respuestas pasan por diferentes capas. Como regla de oro, no de por hecho que las aplicaciones cliente y servidor se conectan directamente entre sí. Puede haber varios intermediarios diferentes en el bucle de comunicación. Las API REST deben diseñarse de modo que ni el cliente ni el servidor puedan saber si se comunica con la aplicación final o con un intermediario.

Las API REST suelen enviar recursos estáticos, pero en ciertos casos, las respuestas también pueden contener código ejecutable (como applets de Java). En estos casos, el código solo debe ejecutarse bajo demanda.

Las API REST se comunican a través de solicitudes HTTP para realizar funciones de base de datos estándar como crear, leer, actualizar y eliminar registros (también conocido como CRUD) dentro de un recurso.

Por ejemplo, una API REST usaría una solicitud GET para recuperar un registro. Una solicitud POST crea un nuevo registro. Una solicitud PUT actualiza un registro y una solicitud DELETE elimina uno. Todos los métodos HTTP se pueden utilizar en las llamadas a la API. Una API REST bien diseñada es similar a un sitio web que se ejecuta en un navegador web con funcionalidad HTTP integrada.

El estado de un recurso en un instante determinado, o marca de tiempo, se conoce como la representación del recurso. Esta información se puede entregar a un cliente en prácticamente cualquier formato, incluidos JavaScript Object Notation (JSON), HTML, XLT, Python, PHP o texto sin formato. JSON es popular porque es legible tanto por humanos como por máquinas y es independiente del lenguaje de programación.

Los encabezados y parámetros de solicitud también son importantes en las llamadas a la API REST, ya que incluyen información importante sobre los identificadores, como metadatos, autorizaciones, identificadores uniformes de recursos (URI), almacenamiento en caché, cookies y mucho más. Los encabezados de solicitud y los encabezados de respuesta, junto con los códigos de estado HTTP convencionales, se utilizan en API REST bien diseñadas.

GraphQL versus REST API: ¿Cuál es la diferencia?

Aunque la flexibilidad es una ventaja significativa del diseño de API REST, esa misma flexibilidad facilita el diseño de una API que no funciona o funciona mal. Por esta razón, los desarrolladores profesionales comparten las buenas prácticas en las especificaciones de la API REST.

La especificación OpenAPI (OAS) establece una interfaz para describir una API de forma que cualquier desarrollador o aplicación pueda descubrirla y comprender completamente sus parámetros y capacidades. Esta información incluye los endpoints disponibles, las operaciones permitidas en cada endpoint, los parámetros de operación, los métodos de autenticación y mucho más. La última versión, OAS3, incluye herramientas prácticas, como OpenAPI Generator, para generar clientes de API y stubs de servidor en diferentes lenguajes de programación.

Proteger una API REST también comienza con las buenas prácticas del sector. Utilice algoritmos de hash para la seguridad de las contraseñas y HTTPS para la transmisión segura de datos. Un marco de autorización como OAuth 2.0puede ayudar a limitar los privilegios de las aplicaciones de terceros.

Con una marca de tiempo en el encabezado HTTP, una API también puede rechazar cualquier solicitud que llegue después de un período de tiempo determinado. La validación de parámetros y los tokens web JSON son otras formas de garantizar que solo los clientes autorizados puedan acceder a la API.