¡Hola! Hoy aprenderemos sobre un tema muy interesante y, lo más importante, muy demandado en el mercado laboral: EL DESCANSO. Dividiremos nuestra descripción general de REST en tres partes:
En la primera parte, cubriremos la historia de REST y describiremos los principios en los que se basa REST.
En el segundo, consideraremos cómo se produce la comunicación entre un cliente y un servidor a través del protocolo HTTP.
En el tercero, escribiremos una pequeña aplicación RESTful que probaremos usando un programa llamado "Postman".
El artículo está dirigido a lectores familiarizados con los siguientes términos:
HTTP
URL y URL
JSON y (en menor medida) XML
Inyección de dependencia
Parte 1. ¿Qué es REST?
REST, como tantas otras cosas en el mundo de TI, es un acrónimo. Se deriva de "Transferencia de estado representacional" . Este es un estilo arquitectónico para la interacción entre los componentes de un sistema distribuido en una red informática. En pocas palabras, REST determina el estilo de interacción (intercambio de datos) entre diferentes componentes del sistema, cada uno de los cuales puede ubicarse físicamente en diferentes lugares. Este estilo arquitectónico es un conjunto coherente de restricciones que se cumplen al diseñar un sistema distribuido. Estas restricciones a veces se denominan los principios rectores de REST. No son muchos, solo 6. Hablaremos de ellos un poco más adelante.
Las aplicaciones creadas teniendo en cuenta los principios REST, es decir, aquellas que no violan las restricciones REST, se denominan "RESTful".
Historia de REST
El término REST fue introducido por Roy Fielding, uno de los creadores del protocolo HTTP, en su Ph.D. tesis titulada "Estilos arquitectónicos y el diseño de arquitecturas de software basadas en red" en 2000. Aunque el término REST todavía puede llamarse joven, el concepto que representa se encuentra en el núcleo mismo de la World Wide Web. No profundizaremos en la historia del término. Si desea sumergirse en las fuentes primarias, eche un vistazo a la disertación de Fielding .
Restricciones y principios de REST
Como se indicó anteriormente, REST define cómo los componentes de un sistema distribuido deben interactuar entre sí. En general, esto sucede a través de un proceso de solicitud-respuesta. El componente que envía la solicitud se denomina cliente , y el componente que procesa la solicitud y envía una respuesta al cliente se denomina servidor .. Las solicitudes y respuestas se envían con mayor frecuencia a través del protocolo HTTP. HTTP significa Protocolo de transferencia de hipertexto. Por lo general, un servidor es una aplicación web. El cliente puede ser casi cualquier cosa. Por ejemplo, una aplicación móvil que solicita datos de un servidor. O un navegador que envía solicitudes desde una página web a un servidor para descargar datos. La aplicación A puede solicitar datos de la aplicación B. En este caso, A es un cliente con respecto a B y B es un servidor con respecto a A. Al mismo tiempo, A podría procesar solicitudes de B, C, D, etc. En este caso, la aplicación A es tanto un servidor como un cliente. Todo depende del contexto. Una cosa es cierta: el componente que envía la solicitud es el cliente. El componente que recibe, procesa y responde a una solicitud es el servidor. Sin embargo, no todos los sistemas cuyos componentes se comunican a través de un proceso de solicitud-respuesta son sistemas RESTful. Para que un sistema se considere RESTful, debe cumplir con las seis restricciones REST:
1. Arquitectura cliente-servidor
Esta restricción se trata de la separación de preocupaciones. Es necesario separar los requisitos de la interfaz del cliente de los requisitos del servidor que almacena los datos. Esta restricción hace que el código del cliente sea más portátil a otras plataformas, y la simplificación del lado del servidor mejora la escalabilidad del sistema. Distinguir entre el "cliente" y el "servidor" permite que se desarrollen de forma independiente el uno del otro.
2. Apátrida
Una arquitectura RESTful requiere que se cumplan las siguientes condiciones. En el período entre solicitudes, el servidor no debe almacenar información sobre el estado del cliente y viceversa. Todas las solicitudes del cliente deben estar compuestas de manera que le brinden al servidor toda la información necesaria para completar la solicitud. Así, tanto el servidor como el cliente pueden "entender" cualquier mensaje recibido, sin depender de mensajes anteriores.
3. Caché
Los clientes pueden almacenar en caché las respuestas del servidor. Estos, a su vez, deben designarse explícita o implícitamente como en caché o no en caché, de modo que los clientes no reciban datos desactualizados o incorrectos en respuesta a solicitudes posteriores. El almacenamiento en caché correcto ayuda a eliminar total o parcialmente algunas interacciones cliente-servidor, lo que aumenta aún más el rendimiento y la escalabilidad del sistema.
4. Interfaz uniforme
Los requisitos fundamentales de una arquitectura RESTful incluyen una interfaz unificada y uniforme. El cliente siempre debe comprender el formato y las direcciones que necesita usar al enviar una solicitud y el servidor, a su vez, también debe comprender el formato que debe usar al responder a las solicitudes del cliente. Esta interacción cliente-servidor consistente que describe qué, dónde, en qué forma y cómo enviar datos es una interfaz unificada.
5. Capas
Por capas, nos referimos a la estructura jerárquica de la red. A veces, un cliente puede comunicarse directamente con el servidor y, a veces, solo se comunica con un nodo intermedio. El uso de servidores intermedios puede aumentar la escalabilidad gracias al equilibrio de carga y el almacenamiento en caché distribuido. Pongamos un ejemplo. Imagine una aplicación móvil que sea popular en todo el mundo. Una parte integral de la aplicación consiste en cargar imágenes. Sus usuarios se cuentan por millones, por lo que un solo servidor no puede manejar una carga tan pesada. Separar el sistema en capas resolverá este problema. Si el cliente solicita una imagen de un nodo intermedio, entonces el nodo intermedio solicita la imagen del servidor que está menos cargado en ese momento y devuelve la imagen al cliente. Si el almacenamiento en caché se aplica correctamente en cada nivel de la jerarquía,
6. Código bajo demanda (opcional)
Esta restricción implica que el cliente puede expandir su funcionalidad descargando código del servidor en forma de applets o scripts.
Ventajas de una arquitectura RESTful
Las aplicaciones que cumplen con todas las restricciones antes mencionadas tienen las siguientes ventajas: confiabilidad (no es necesario guardar el estado del cliente, que podría perderse)
rendimiento (debido al uso de un caché)
escalabilidad
comunicación transparente
interfaces simples
portabilidad
capacidad de hacer cambios fácilmente
capacidad de evolucionar y adaptarse a nuevos requisitos
Dividiremos nuestra descripción general de REST en tres partes:
GO TO FULL VERSION