¿Qué es REST API?

REST API es una API HTTP (a veces llamada API web) construida según los principios de la arquitectura REST. El término REST fue introducido por Roy Fielding en su tesis doctoral "Architectural Styles and the Design of Network-based Software Architectures" en el año 2000. Muchos prestaron atención a esta tesis porque Roy no era una persona aleatoria en la industria. Este científico fue uno de los principales desarrolladores del protocolo HTTP/1.0 y autor del HTTP/1.1. También participó en el desarrollo del lenguaje HTML y el estándar URI. Además, fue coautor del servidor web Apache, que en su momento fue el más popular del mundo.

Una pequeña digresión. Alrededor de REST existen muchas conjeturas, detrás de las cuales se ha perdido la esencia y muchos programadores tienen una comprensión distorsionada de REST. En gran medida, esto se debe al proceso de aprendizaje de la programación. Los desarrolladores aprenden sobre REST a través de la documentación de los frameworks, que solo revelan algunos detalles sin mostrar el panorama completo. Es comprensible, los frameworks no tienen como objetivo enseñar a las personas sobre arquitectura, su tarea es proporcionar una herramienta y enseñar a usarla.

Antes de discutir específicamente qué son los principios de REST, es necesario hablar un poco sobre su historia. En términos generales, REST no se trata de cómo hacer una API HTTP. REST se trata de cómo debería haber sido construido todo el WEB según ciertos principios.

Es decir, REST no surgió para ordenar la WEB, sino que la WEB se volvió así para cumplir con REST.

El término "REST" fue introducido por Roy Fielding, uno de los creadores del protocolo "HTTP", solo en el año 2000. En su tesis doctoral "Architectural Styles and the Design of Network-based Software Architectures" en la Universidad de California en Irvine, sentó las bases teóricas para la forma en que los clientes y servidores interactúan en la World Wide Web, abstrayéndola y llamándola "transferencia de estado representacional".

Para que el protocolo de interacción cumpla con el estilo REST, se deben cumplir al menos 5 requisitos. Si un servicio cumple solo parte de ellos, se dice que es REST-like. Si se cumplen todos los requisitos, el protocolo es RESTful. En la práctica, hay situaciones en las que no es posible cumplir con los requisitos de REST, por lo que la mayoría de los protocolos son REST-like, incluso si afirman lo contrario.

En la tabla a continuación, se puede ver que cada URN es un identificador de un recurso único o una colección de recursos (que también es un recurso), y las acciones necesarias se especifican mediante el uso del método HTTP adecuado. Y todo esto debe suceder en estricta conformidad con la semántica de HTTP, en otras palabras, REST utiliza lo que está incorporado en HTTP, en lugar de cambiarlo o agregar algo propio.

Al igual que en la World Wide Web, cada uno de los clientes, así como los nodos intermedios entre el servidor y los clientes, pueden almacenar en caché las respuestas del servidor. Cada solicitud del cliente debe incluir explícitamente una indicación de la posibilidad de almacenar en caché la respuesta y obtenerla de la caché existente. A su vez, las respuestas pueden definirse explícita o implícitamente como cachéables o no cachéables para evitar que la información almacenada se reutilice en solicitudes posteriores por parte de los clientes. El uso adecuado de la caché en la arquitectura REST elimina las interacciones innecesarias entre el cliente y el servidor, lo que mejora la velocidad y la escalabilidad del sistema.

El protocolo de interacción entre el cliente y el servidor no guarda ningún estado de sesión después de la solicitud y la respuesta (Stateless protocol). En caso de necesidad, dicho estado debe mantenerse en el cliente. Solo así el usuario estará desvinculado de un servidor específico, lo que a su vez permite escalar y transferir (balancear) las solicitudes entre servidores sin problemas.

Un ejemplo de tal estado es el carrito de compras en una tienda en línea. Si está vinculado a una sesión de usuario y se almacena en un servidor específico (en lugar de en el navegador del cliente), no será posible enviar la solicitud del usuario a otro servidor. Simplemente no verá su carrito. Este problema se puede resolver de dos maneras. El primero es almacenarlo en el cliente utilizando, por ejemplo, cookie. El segundo es cambiar la forma en que se almacena el carrito en el servidor y colocarlo en una base de datos accesible desde todos los servidores.

En la práctica, los sitios web utilizan activamente el concepto de "sesiones", donde los datos pueden almacenarse en el servidor, lo cual es una violación de REST.

La separación de las necesidades es el principio subyacente de esta restricción impuesta. Al separar las necesidades de la interfaz del cliente de las necesidades del servidor que almacena los datos, se mejora la portabilidad del código de la interfaz del cliente a otras plataformas, y al simplificar la parte del servidor se mejora la escalabilidad.

El cliente puede interactuar no directamente con el servidor, sino a través de nodos intermedios (capas). En este caso, el cliente puede no ser consciente de su existencia, excepto en casos de transferencia de información confidencial. Los servidores intermedios realizan el equilibrio de carga y pueden utilizar almacenamiento en caché adicional.a.

REST puede permitir ampliar la funcionalidad del cliente mediante la carga de código desde el servidor en forma de applets o scripts. Fielding afirma que esta restricción adicional permite diseñar una arquitectura que admita la funcionalidad deseada en general, pero puede no ser aplicable en algunos contextos.

Fielding señaló que las aplicaciones que no cumplen con las condiciones mencionadas no pueden considerarse aplicaciones REST. Si se cumplen todas las condiciones, según él, la aplicación obtendrá las siguientes ventajas:

Hablando en términos generales, REST es un conjunto de recomendaciones sobre cómo hacer las cosas para obtener las ventajas descritas en el párrafo anterior. Cuantas más recomendaciones sigas, más RESTful será tu aplicación. Y dado que la vida es complicada, es normal que los servicios orientados a REST solo sean parcialmente RESTful. El uso de REST como una doctrina no conducirá a nada bueno. Y REST de ninguna manera reemplaza a RPC. La elección de la solución depende de la situación y los requisitos planteados.

Aunque REST parece bueno, todavía está demasiado lejos de las implementaciones concretas y solo describe los aspectos fundamentales de la interacción. Tendrás que pensar en los métodos específicos de organización de las URL, los datos transmitidos, el comportamiento en caso de errores y mucho más por tu cuenta.

Hay otro camino. En 2013, se creó un estándar llamado jsonapi, que describe en detalle cómo crear servicios REST-like. Se han desarrollado muchas bibliotecas para implementar este estándar en todos los lenguajes de programación populares. Como mínimo, te recomendaría que te familiarices con él y, mejor aún, lo adoptes. El uso de estándares abiertos en la programación industrial hace nuestra vida más fácil, enriquece los negocios y hace que nuestro cabello sea más sedoso.