REST ( transferencia de estado representacional ) es un estilo arquitectónico de software que se creó 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 interfaces uniformes, 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 sistemas heredados . [1]
REST se ha empleado en toda la industria del software para crear aplicaciones basadas en web confiables y sin estado . Una aplicación que cumple con las restricciones arquitectónicas REST puede describirse informalmente como RESTful . Sin embargo, este término se asocia más comúnmente con el diseño de API basadas en HTTP y lo que se consideran mejores prácticas con respecto a los "verbos" ( métodos HTTP ) a los que responde un recurso , aunque tiene poco que ver con REST tal como se formuló originalmente, y a menudo se incluso en desacuerdo con el concepto. [2]
El término transferencia de estado representacional fue introducido y definido en 2000 por el informático Roy Fielding en su tesis doctoral. Significa que un servidor responderá con la representación de un recurso (hoy en día, con mayor frecuencia será 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 es necesario conocer es el identificador del primer recurso solicitado, y todos los demás identificadores serán descubiertos. Esto significa que esos identificadores pueden cambiar sin necesidad de informar al cliente de antemano y que sólo puede haber un acoplamiento flojo entre el cliente y el servidor.
La Web comenzó a ser de uso cotidiano en 1993-1994, cuando comenzaron a estar disponibles sitios web para uso general . [3] En ese momento, sólo habí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 agregado varias extensiones experimentales al protocolo de comunicación (HTTP) para admitir servidores proxy y se estaban proponiendo más extensiones. Aún así, 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 estuvo involucrado 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 e identificar discrepancias arquitectónicas. Fielding definió REST en su tesis doctoral de 2000 "Estilos arquitectónicos y 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 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 intentaba 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. Si bien 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. Los desajustes pueden ocurrir debido a desconocimiento o descuido, pero la existencia del estilo arquitectónico REST significa que pueden identificarse antes de que se estandaricen. Por ejemplo, Fielding identificó la incorporación de información de sesión en URI como una violación de las restricciones de REST que puede afectar negativamente el almacenamiento en caché compartido y la escalabilidad del servidor. Las cookies HTTP también violaron las restricciones REST porque pueden desincronizarse con el estado de la aplicación del navegador, lo que las hace poco confiables; 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.
El fuerte desacoplamiento entre cliente y servidor junto con la transferencia de información basada en texto utilizando un protocolo de direccionamiento uniforme proporcionó la base para cumplir con los requisitos de la Web: robustez (escalabilidad anárquica), implementación independiente de componentes, transferencia de datos de gran tamaño y una barrera de entrada baja para lectores de contenido, autores de contenido y desarrolladores por igual.
Las restricciones del estilo arquitectónico REST afectan las siguientes propiedades arquitectónicas: [1] [6]
El estilo arquitectónico REST define seis limitaciones rectoras. [6] [8] Cuando estas restricciones se aplican a la arquitectura del sistema, obtiene propiedades no funcionales deseables , como rendimiento, escalabilidad, simplicidad, modificabilidad, visibilidad, portabilidad y confiabilidad. [1]
Las restricciones formales de REST 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 cumplimiento de varios principios de diseño REST, como
Las API de servicios web que cumplen con las restricciones arquitectónicas REST se denominan API RESTful. [13] Las API RESTful basadas en HTTP se definen con los siguientes aspectos: [14]
A diferencia de los servicios web basados en SOAP , no existe un estándar "oficial" para las API web RESTful. Esto se debe a que REST es un estilo arquitectónico, mientras que SOAP es un protocolo. REST no es un estándar en sí mismo, pero las implementaciones RESTful utilizan estándares, como HTTP , URI , JSON y XML . Muchos desarrolladores describen sus API como RESTful, aunque estas API no cumplen con todas las restricciones arquitectónicas descritas anteriormente (especialmente la restricción de interfaz uniforme). [2] La mayoría de las API que afirman ser RESTful solo satisfacen el nivel 2 del modelo de madurez de Richardson .