¿Qué es la API REST?

Definido en 2000 por el informático DRr. 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 construir 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 tiene acceso 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. Sin embargo, los desarrolladores pueden desarrollar API REST utilizando prácticamente cualquier lenguaje de programación y admitir 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 la API REST, las aplicaciones de cliente y de servidor deben ser completamente 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 general, no asuma que las aplicaciones de cliente y de 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 a petición.

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 vs. REST API: ¿Cuál es la diferencia?

Aunque la flexibilidad es una gran ventaja del diseño de la API REST, esa misma flexibilidad facilita el diseño de una API que se rompe 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 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 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.