DESCANSAR

REST ( Representational State Transfer ) es un estilo arquitectónico de software creado para describir el diseño y guiar el desarrollo de la arquitectura de la World Wide Web . REST define un conjunto de restricciones sobre cómo debe comportarse la arquitectura de un sistema hipermedia distribuido a escala de Internet , como la Web. El estilo arquitectónico REST enfatiza las interfaces uniformes , el despliegue independiente de componentes , la escalabilidad de las interacciones entre ellos y la creación de una arquitectura en capas para promover el almacenamiento en caché , reducir la latencia percibida por el usuario , reforzar la seguridad y encapsular sistemas heredados . ^{[ 1 ]}

REST se ha empleado en toda la industria del software para crear aplicaciones web fiables y sin estado . Una aplicación que se adhiere a las restricciones arquitectónicas de REST puede describirse informalmente como RESTful , aunque este término se asocia más comúnmente con el diseño de API basadas en HTTP y con lo que se consideran buenas prácticas en relación con los "verbos" ( métodos HTTP ) a los que responde un recurso , teniendo poco que ver con REST tal como se formuló originalmente, e incluso a menudo contradictorio con el concepto. ^{[ 2 ]}

El término transferencia de estado representacional fue introducido y definido en el año 2000 por el informático Roy Fielding en su tesis doctoral. Significa que un servidor responde con la representación de un recurso (generalmente un documento HTML ), el cual contiene enlaces de hipermedia que permiten modificar el estado del sistema. Cualquier solicitud de este tipo, a su vez, recibe la representación del recurso, y así sucesivamente.

Una consecuencia importante es que el único identificador que se necesita conocer es el del primer recurso solicitado, y todos los demás identificadores se descubrirán automáticamente. Esto significa que dichos identificadores pueden cambiar sin necesidad de informar al cliente con antelación y que el cliente y el servidor deben estar inherentemente poco acoplados .

La Web comenzó a utilizarse en la vida cotidiana entre 1993 y 1994, cuando empezaron a estar disponibles los sitios web de uso general . ^{[ 3 ]} En aquel momento, solo existía una descripción fragmentada de la arquitectura de la Web, y había presión dentro de la comunidad para acordar un estándar para los protocolos de interfaz web. Por ejemplo, se habían añadido varias extensiones experimentales al protocolo de comunicación (HTTP) para admitir proxies , y se estaban proponiendo más extensiones, pero era necesario contar con una arquitectura web formal con la que evaluar el impacto de estos cambios. ^{[ 4 ]}

Los grupos de trabajo del W3C y el IETF comenzaron a trabajar juntos en la creación de descripciones formales de los tres estándares principales de la Web: URI , HTTP y HTML . Roy Fielding participó en la creación de estos estándares (específicamente HTTP 1.0 y 1.1, y URI), y durante los siguientes seis años creó el estilo arquitectónico REST, probando sus restricciones en los estándares de protocolo de la Web y usándolo como un medio para definir mejoras arquitectónicas , y para identificar desajustes arquitectónicos. Fielding definió REST en su disertación doctoral de 2000 "Estilos arquitectónicos y el diseño de arquitecturas de software basadas en redes" ^{[ 1 ] [ 5 ]} en UC Irvine .  

Para crear el estilo arquitectónico REST, Fielding identificó los requisitos que se aplican al crear una aplicación basada en red global, como la necesidad de una baja barrera de entrada para facilitar su adopción mundial. También analizó numerosos estilos arquitectónicos existentes para aplicaciones basadas en red, identificando las características compartidas con otros estilos, como el almacenamiento en caché y las funcionalidades cliente-servidor, y aquellas exclusivas de REST, como el concepto de recursos. Fielding buscaba, por un lado, categorizar la arquitectura de la implementación existente y, por otro, identificar los aspectos que debían considerarse fundamentales para los requisitos de comportamiento y rendimiento de la Web.

Por su naturaleza, los estilos arquitectónicos son independientes de cualquier implementación específica, y si bien REST se creó como parte del desarrollo de los estándares web, la implementación de la web no obedece todas las restricciones del estilo arquitectónico REST. Pueden producirse discrepancias debido a la ignorancia o a la omisión, pero la existencia del estilo arquitectónico REST significa que pueden identificarse antes de que se estandaricen. Por ejemplo, Fielding identificó la incrustación de información de sesión en URI como una violación de las restricciones de REST que puede afectar negativamente al almacenamiento en caché compartido y a la escalabilidad del servidor. Las cookies HTTP también violan las restricciones de REST ^{[ 4 ]} porque pueden desincronizarse con el estado de la aplicación del navegador, lo que las hace poco fiables; también contienen datos opacos que pueden ser una preocupación para la privacidad y la seguridad .

El estilo arquitectónico REST está diseñado para aplicaciones basadas en red, específicamente aplicaciones cliente-servidor. Pero, además, está diseñado para su uso a escala de Internet, por lo que el acoplamiento entre el agente de usuario (cliente) y el servidor de origen debe ser lo más flexible posible para facilitar su adopción a gran escala.

El fuerte desacoplamiento del cliente y el servidor, junto con la transferencia de información basada en texto mediante un protocolo de direccionamiento uniforme, proporcionó la base para cumplir con los requisitos de la Web: extensibilidad , escalabilidad anárquica ^{[ 6 ]} y despliegue independiente de componentes, transferencia de datos de grano grueso y una baja barrera de entrada para lectores de contenido, autores de contenido y desarrolladores.

Las restricciones del estilo arquitectónico REST afectan las siguientes propiedades arquitectónicas: ^{[ 1 ] [ 7 ]}

• El rendimiento en las interacciones de los componentes, que puede ser el factor dominante en el rendimiento percibido por el usuario y la eficiencia de la red; ^{[ 8 ]}
• Escalabilidad que permite la compatibilidad con un gran número de componentes e interacciones entre ellos;
• Sencillez de una interfaz uniforme;
• Modificabilidad ( también conocida como extensibilidad ) de los componentes para satisfacer necesidades cambiantes (incluso mientras la aplicación está en ejecución);
• Visibilidad de la comunicación entre componentes por parte de los agentes de servicio;
• Portabilidad de componentes mediante el traslado del código del programa junto con los datos;
• Fiabilidad en la resistencia a fallos a nivel del sistema en presencia de fallos en componentes, conectores o datos. ^{[ 8 ]}

El estilo arquitectónico REST define seis restricciones rectoras. ^{[ 7 ] [ 9 ]} Cuando estas restricciones se aplican a la arquitectura del sistema, este adquiere propiedades no funcionales deseables , como rendimiento, escalabilidad, simplicidad, modificabilidad, visibilidad, portabilidad y fiabilidad. ^{[ 1 ]}

Las restricciones REST formales son las siguientes: ^{[ 10 ]}

• Cliente/Servidor: Los clientes están separados de los servidores por una interfaz bien definida.
• Sin estado: un cliente específico no consume almacenamiento del servidor cuando está "en reposo".
• Caché: las respuestas indican su propia capacidad de almacenamiento en caché.
• Interfaz uniforme
• Sistema en capas: un cliente normalmente no puede saber si está conectado directamente al servidor final o a un intermediario en el camino.
• Código bajo demanda (opcional): los servidores pueden extender o personalizar temporalmente la funcionalidad de un cliente transfiriendo lógica al cliente que puede ejecutarse dentro de una máquina virtual estándar.

Se han desarrollado varios modelos para ayudar a clasificar las API HTTP según su adhesión a diversos principios de diseño REST, como por ejemplo:

• El modelo de madurez de Richardson
• Clasificación de las API basadas en HTTP ^{[ 12 ]}
• el modelo de madurez WS ^{3 [ 13 ]}

• URL limpia : URL destinada a mejorar la usabilidad de un sitio web. 
• Red de entrega de contenido : capa del ecosistema de Internet que resuelve los cuellos de botella. 
• Protocolo de aplicación de dominio (DAP)
• Lista de esquemas URI : identificador de espacio de nombres asignado por IANA. 
• Microservicios : conjunto de servicios débilmente acoplados que se utilizan para construir aplicaciones informáticas. 
• Descripción general de los lenguajes de descripción de API RESTful : descripciones de lenguajes informáticos. 
• Arquitectura orientada a recursos : patrón arquitectónico en el diseño de software. 
• Computación orientada a recursos : patrón arquitectónico en el diseño de software 
• Arquitectura orientada a servicios : patrón arquitectónico en el diseño de software. 
• Arquitectura orientada a la web : patrón arquitectónico en el diseño de software. 
• Servicio web : servicio ofrecido entre dispositivos electrónicos a través de Internet. 

• Pautasso, Cesare; Wilde, Erik; Alarcon, Rosa (2014), REST: Temas de investigación avanzada y aplicaciones prácticas , Springer, ISBN 9781461492986
• Pautasso, Cesare; Zimmermann, Olaf; Leymann, Frank (abril de 2008), «Servicios web RESTful frente a servicios web "grandes"», Actas de la 17.ª conferencia internacional sobre la World Wide Web , págs. 805-814 , doi : 10.1145/1367497.1367606 , ISBN  9781605580852, S2CID 207167438 
• Ferreira, Otavio (noviembre de 2009), Servicios web semánticos: un enfoque RESTful , IADIS, ISBN 978-972-8924-93-5
• Fowler, Martin (18 de marzo de 2010). "Modelo de madurez de Richardson: pasos hacia la gloria de REST" . martinfowler.com . Consultado el 26 de junio de 2017 .