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 para 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 soportar 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 violan las restricciones de REST 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 proporcionó 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]
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]
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:
Se han desarrollado varios modelos para ayudar a clasificar las API REST según su adherencia a varios principios de diseño REST, como