Hola, hoy estudiaremos un tema muy interesante y, lo más importante, muy demandado en el mercado laboral: REST. Dividiremos la descripción general de REST en tres partes:
En la primera parte, abordaremos la historia de REST y describiremos los principios en los que se basa REST.
En el segundo, veremos cómo se produce la comunicación entre el cliente y el servidor a través del protocolo HTTP.
En el tercero, escribiremos una pequeña aplicación RESTful, que probaremos usando el programa Postman.
El artículo está dirigido a un lector familiarizado con los siguientes términos:
HTTP;
URL y URI;
JSON y en menor medida XML;
Inyección de dependencia.
Parte 1. ¿Qué es el DESCANSO?
REST, como muchas cosas en el mundo de TI, es un acrónimo de Representational State Transfer . Este es un estilo arquitectónico de interacción entre componentes de un sistema distribuido en una red informática. En pocas palabras, REST define un estilo de interacción (intercambio de datos) entre diferentes componentes de un sistema, cada uno de los cuales puede estar ubicado físicamente en diferentes lugares. Este estilo arquitectónico representa un conjunto consistente de restricciones que se consideran al diseñar un sistema distribuido. Estas restricciones a veces se denominan principios REST. No hay muchos, solo 6 piezas. Hablaremos de ellos un poco más tarde.
Aplicaciones creadas teniendo en cuenta REST, es decir. que no violan las restricciones impuestas por REST se denominan RESTful.
Historia del DESCANSO
El término REST fue acuñado por Roy Fielding, uno de los creadores del protocolo HTTP, en su tesis doctoral "Estilos arquitectónicos y diseño de arquitecturas de software basadas en red" en el año 2000. Podemos decir que el término REST es aún joven, aunque su concepto se encuentra en la base misma de la World Wide Web. No profundizaremos en la historia del origen de este término. Si desea profundizar en las fuentes originales, eche un vistazo a la disertación de Fielding .
Restricciones y principios REST
Como se indicó anteriormente, REST define cómo los componentes de un sistema distribuido deben interactuar entre sí. En general, esto sucede mediante solicitud-respuesta. El componente que envía la solicitud se llama cliente ; El componente que procesa la solicitud y envía una respuesta al cliente se llama servidor . Las solicitudes y respuestas se envían con mayor frecuencia a través de HTTP (Protocolo de transferencia de hipertexto). Normalmente, un servidor es algún tipo de aplicación web. El cliente no puede ser cualquier cosa, sino mucho. Por ejemplo, una aplicación móvil que solicita datos al 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. Entonces A es un cliente en relación con B y B es un servidor en relación con A. Al mismo tiempo, A puede procesar solicitudes de C, D, D, etc. En este caso, la aplicación A es tanto un servidor como un cliente. Todo depende del contexto. Una cosa está clara: el componente que envía la solicitud es el cliente. El componente que recibe, procesa y responde a la solicitud es el servidor. Sin embargo, no todos los sistemas cuyos componentes se comunican mediante solicitud-respuesta son sistemas REST (o RESTful). Para que un sistema se considere RESTful, debe "ajustarse" a seis restricciones REST:
1. Llevar la arquitectura a un modelo cliente-servidor
La base de esta limitación es la diferenciación de necesidades. Es necesario separar las necesidades de la interfaz del cliente de las necesidades del servidor que almacena los datos. Esta limitación aumenta la portabilidad del código del cliente a otras plataformas y la simplificación de la parte del servidor mejora la escalabilidad del sistema. La propia distinción entre “cliente” y “servidor” les permite desarrollarse independientemente uno del otro.
2. Falta de condición
La arquitectura REST requiere que se cumpla la siguiente condición. Entre solicitudes, el servidor no necesita almacenar información sobre el estado del cliente y viceversa. Todas las solicitudes del cliente deben estructurarse de modo que el servidor reciba toda la información necesaria para completar la solicitud. De esta forma, tanto el servidor como el cliente pueden “comprender” cualquier mensaje recibido sin depender de mensajes anteriores.
3. Almacenamiento en caché
Los clientes pueden almacenar en caché las respuestas del servidor. Estos, a su vez, deben designarse explícita o implícitamente como almacenables en caché o no almacenables en caché, de modo que los clientes no reciban datos obsoletos o incorrectos en respuesta a solicitudes posteriores. El uso adecuado del almacenamiento en caché ayuda a eliminar algunas interacciones cliente-servidor, total o parcialmente, aumentando aún más el rendimiento y la extensibilidad del sistema.
4. Uniformidad de la interfaz.
Los requisitos fundamentales de la arquitectura REST incluyen una interfaz unificada y consistente. El cliente siempre debe comprender en qué formato y a qué direcciones debe enviar una solicitud, y el servidor, a su vez, también debe comprender en qué formato debe responder a las solicitudes del cliente. Este es un formato unificado para la interacción cliente-servidor, que describe qué, dónde, en qué forma y cómo enviar y es una interfaz unificada.
5. Capas
Las capas se refieren a la estructura jerárquica de las redes. A veces, el cliente puede comunicarse directamente con el servidor y, a veces, simplemente puede comunicarse con un nodo intermedio. El uso de servidores intermedios puede aumentar la escalabilidad mediante el equilibrio de carga y el almacenamiento en caché distribuido. Pongamos un ejemplo. Imaginemos una aplicación móvil que sea popular en todo el mundo. Su parte integral es la carga de imágenes. Como hay millones de usuarios, un servidor no podría soportar una carga tan pesada. Dividir el sistema en capas resolverá este problema. El cliente solicitará una imagen al nodo intermedio, el nodo intermedio solicitará la imagen al servidor que esté menos cargado en ese momento y devolverá la imagen al cliente. Si el almacenamiento en caché se aplica correctamente aquí en cada nivel de la jerarquía, entonces se puede lograr una buena escalabilidad del sistema.
6. Código bajo demanda (restricción opcional)
Esta limitación implica que el cliente puede ampliar su funcionalidad descargando código del servidor en forma de subprogramas o scripts.
Los beneficios del DESCANSO
Las aplicaciones que cumplen con todas las restricciones anteriores tienen las siguientes ventajas: confiabilidad (no es necesario almacenar información del estado del cliente, que puede perderse);
rendimiento (debido al uso de caché);
escalabilidad;
transparencia del sistema de interacción;
simplicidad de interfaces;
portabilidad de componentes;
facilidad para realizar cambios;
la capacidad de evolucionar, adaptándose a los nuevos requerimientos.
GO TO FULL VERSION