DESCANSAR

REST ( Representational State Transfer ) es un estilo arquitectónico de software que fue creado para guiar el diseño y desarrollo de la arquitectura para 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 , la implementación 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é para reducir la latencia percibida por el usuario , reforzar la seguridad y encapsular los sistemas heredados . ^[1]

REST se ha utilizado en toda la industria del software para crear aplicaciones web confiables 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 lo que se considera ampliamente como las mejores prácticas con respecto a los "verbos" ( métodos HTTP ) a los que responde un recurso , mientras que tiene poco que ver con REST tal como se formuló originalmente, y a menudo incluso está en desacuerdo con el concepto. ^[2]

El término transferencia de estado representacional fue introducido y definido en el año 2000 por el científico informático Roy Fielding en su tesis doctoral. Significa que un servidor responderá con la representación de un recurso (hoy en día, lo más frecuente es que sea un documento HTML , XML o JSON ) y ese recurso contendrá enlaces hipermedia que se pueden seguir para hacer que el estado del sistema cambie. Cualquier solicitud de este tipo recibirá a su vez la representación de un recurso, y así sucesivamente.

Una consecuencia importante es que el único identificador que se necesita conocer es el identificador del primer recurso solicitado, y todos los demás identificadores se descubrirán. Esto significa que esos identificadores pueden cambiar sin necesidad de informar al cliente de antemano y que solo puede haber un acoplamiento débil entre el cliente y el servidor.

La Web empezó a ser utilizada de forma cotidiana en 1993-1994, cuando empezaron a estar disponibles los sitios web de uso general . ^[3] En ese momento, sólo existía una descripción fragmentada de la arquitectura de la Web, y había presión en la industria para acordar algún 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 dar soporte a los proxies , y se estaban proponiendo más extensiones, pero existía la necesidad de una arquitectura Web formal con la que evaluar el impacto de estos cambios. ^[4]

Los grupos de trabajo del W3C y del 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 utilizándolo como un medio para definir mejoras arquitectónicas y para identificar desajustes arquitectónicos. Fielding definió REST en su tesis doctoral de 2000 "Architectural Styles and the Design of Network-based Software Architectures" ^{[1] [5]} en la UC Irvine .

Para crear el estilo arquitectónico REST, Fielding identificó los requisitos que se aplican al crear una aplicación basada en red mundial, como la necesidad de una barrera de entrada baja para permitir la adopción global. También examinó muchos estilos arquitectónicos existentes para aplicaciones basadas en red, identificando qué características se comparten con otros estilos, como el almacenamiento en caché y las características cliente-servidor, y aquellas que son exclusivas de REST, como el concepto de recursos. Fielding estaba tratando de categorizar la arquitectura existente de la implementación actual e identificar qué aspectos deberían considerarse centrales 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 aunque REST se creó como parte del desarrollo de los estándares web, la implementación de la web no obedece a todas las restricciones del estilo arquitectónico REST. Pueden producirse desajustes debido a la ignorancia o al descuido, pero la existencia del estilo arquitectónico REST significa que se pueden identificar antes de que se estandaricen. Por ejemplo, Fielding identificó la incorporación de información de sesión en las 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 violaron las restricciones de REST ^[4] porque pueden desincronizarse con el estado de la aplicación del navegador, lo que las vuelve poco fiables; también contienen datos opacos que pueden ser un problema 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 más que eso, está diseñado para 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 la adopción a gran escala.

La fuerte disociación entre cliente y servidor junto con la transferencia de información basada en texto utilizando un protocolo de direccionamiento uniforme proporcionaron la base para satisfacer los requisitos de la Web: extensibilidad , escalabilidad anárquica ^{[ cita requerida ]} y despliegue independiente de componentes, transferencia de datos de gran grano 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] [6]}

• 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; ^[7]
• Escalabilidad que permite soportar un gran número de componentes e interacciones entre componentes;
• Simplicidad de una interfaz uniforme;
• Modificabilidad 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 moviendo el código del programa con los datos;
• Confiabilidad en la resistencia a fallas a nivel de sistema en presencia de fallas dentro de componentes, conectores o datos. ^[7]

El estilo arquitectónico REST define seis restricciones rectoras. ^{[6] [8]} Cuando estas restricciones se aplican a la arquitectura del sistema, esta obtiene propiedades no funcionales deseables , como rendimiento, escalabilidad, simplicidad, modificabilidad, visibilidad, portabilidad y confiabilidad. ^[1]

Las restricciones REST formales son las siguientes: ^[9]

• 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 el cliente 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 a pedido (opcional): los servidores pueden ampliar o personalizar temporalmente la funcionalidad de un cliente transfiriendo lógica al cliente que se puede ejecutar dentro de una máquina virtual estándar.

La restricción de interfaz uniforme es fundamental para el diseño de cualquier sistema RESTful. ^[1] Simplifica y desacopla la arquitectura, lo que permite que cada parte evolucione de forma independiente. Las cuatro restricciones para esta interfaz uniforme son:

• Identificación de recursos en las solicitudes: los recursos individuales se identifican en las solicitudes mediante URI . Los recursos en sí mismos están conceptualmente separados de las representaciones que se devuelven al cliente. Por ejemplo, el servidor podría enviar datos desde su base de datos como HTML , XML o JSON , ninguno de los cuales es la representación interna del servidor.
• Manipulación de recursos a través de representaciones: cuando un cliente tiene una representación de un recurso, incluidos todos los metadatos adjuntos, tiene suficiente información para modificar o eliminar el estado del recurso.
• Mensajes autodescriptivos: cada mensaje incluye suficiente información para describir cómo procesar el mensaje. Por ejemplo, se puede especificar qué analizador invocar mediante un tipo de medio . ^[1]
• Hipermedia como motor del estado de la aplicación ( HATEOAS ): después de haber accedido a una URL inicial para la aplicación REST (de forma análoga a la que un usuario web humano accede a la página de inicio de un sitio web), un cliente REST debería poder utilizar los enlaces proporcionados por el servidor de forma dinámica para descubrir todos los recursos disponibles que necesita. A medida que se realiza el acceso, el servidor responde con un texto que incluye hipervínculos a otros recursos que están disponibles en ese momento. No es necesario que el cliente esté codificado con información sobre la estructura del servidor. ^[10]

Se han desarrollado varios modelos para ayudar a clasificar las API REST según su adherencia a varios principios de diseño REST, como

• El modelo de madurez de Richardson
• La clasificación de las API basadas en HTTP ^[11]
• El modelo de madurez WS ^{3 [12]}

• URL limpia  : URL destinada a mejorar la usabilidad de un sitio web
• Red de distribución de contenidos  : una capa en el ecosistema de Internet que aborda 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 acoplados de forma flexible que se utilizan para crear aplicaciones informáticas.
• Descripción general de los lenguajes de descripción de API RESTful  : descripciones de interfaces de red informáticaPáginas que muestran descripciones de wikidata como alternativa
• 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
• Servicios web  : Servicios ofrecidos entre dispositivos electrónicos a través de Internet.Páginas que muestran descripciones breves de los objetivos de redireccionamiento

• Pautasso, Cesare; Wilde, Erik; Alarcon, Rosa (2014), REST: Temas de investigación avanzados 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, Número de identificación del sujeto  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). "Richardson Maturity Model: steps toward the glory of REST" (Modelo de madurez de Richardson: pasos hacia la gloria de REST). martinfowler.com . Consultado el 26 de junio de 2017 .