Transferencia de estado representacional

Estándar de arquitectura de software para aplicaciones que utilizan servicios web interoperables

"REST" vuelve a dirigir aquí. Para otros usos, consulte Descanso .

Este artículo puede ser demasiado técnico para que la mayoría de los lectores lo comprendan . Ayude a mejorarlo para que sea comprensible para los no expertos , sin eliminar los detalles técnicos. ( Octubre de 2020 ) ( Obtenga información sobre cómo y cuándo eliminar este mensaje de plantilla )

La transferencia de estado representacional ( REST ) es un estilo de arquitectura de software que utiliza un subconjunto de HTTP . ^[1] Se utiliza comúnmente para crear aplicaciones interactivas que utilizan servicios web . Un servicio web que sigue estas pautas se llama RESTful . Dicho servicio web debe proporcionar sus recursos web en una representación textual y permitir que se lean y modifiquen con un protocolo sin estado y un conjunto predefinido de operaciones. Este enfoque permite la interoperabilidad entre los sistemas informáticos en Internet.que prestan estos servicios. REST es una alternativa a, por ejemplo, SOAP como forma de acceder a un servicio web. ^[2]

Los "recursos web" se definieron por primera vez en la World Wide Web como documentos o archivos identificados por sus URL . Hoy en día, la definición es mucho más genérica y abstracta, e incluye todo lo, entidad o acción que se puede identificar, nombrar, abordar, manejar o realizar de cualquier forma en la Web. En un servicio web RESTful, las solicitudes realizadas al URI de un recurso generan una respuesta con una carga útil formateada en HTML , XML , JSON o algún otro formato. Por ejemplo, la respuesta puede confirmar que se ha cambiado el estado del recurso. La respuesta también puede incluir hipertexto.enlaces a recursos relacionados. El protocolo más común para estas solicitudes y respuestas es HTTP. Proporciona operaciones ( métodos HTTP ) GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS y TRACE. ^[3]

Al utilizar un protocolo sin estado y operaciones estándar, los sistemas RESTful apuntan a un rendimiento rápido, confiabilidad y la capacidad de crecer mediante la reutilización de componentes que se pueden administrar y actualizar sin afectar el sistema en su conjunto, incluso mientras está en ejecución.

El término transferencia de estado representacional fue introducido y definido en 2000 por Roy Fielding en su tesis doctoral. ^{[1] [4]} La disertación de Fielding explicó los principios REST que se conocían como el "modelo de objeto HTTP" a partir de 1994, y se utilizaron en el diseño de los estándares HTTP 1.1 y Uniform Resource Identifiers (URI). ^{[5] [6]} El término pretende evocar una imagen de cómo se comporta una aplicación web bien diseñada: es una red de recursos web (una máquina de estado virtual) donde el usuario avanza a través de la aplicación seleccionando identificadores de recursos como http: // www. .example.com / articles / 21 y operaciones de recursos como GET o POST (transiciones de estado de la aplicación), lo que da como resultado que la representación del siguiente recurso (el siguiente estado de la aplicación) se transfiera al usuario final para su uso.

Historia

Roy Fielding hablando en OSCON 2008.

Roy Fielding definió REST en su disertación de doctorado de 2000 "Estilos arquitectónicos y el diseño de arquitecturas de software basadas en redes" en UC Irvine . ^[1] Desarrolló el estilo arquitectónico REST en paralelo con HTTP 1.1 de 1996-1999, basado en el diseño existente de HTTP 1.0 ^[7] de 1996.

En una mirada retrospectiva al desarrollo de REST, Fielding dijo:

Durante todo el proceso de estandarización de HTTP, se me pidió que defendiera las opciones de diseño de la Web. Eso es algo extremadamente difícil de hacer dentro de un proceso que acepta propuestas de cualquiera sobre un tema que se estaba convirtiendo rápidamente en el centro de toda una industria. Recibí comentarios de más de 500 desarrolladores, muchos de los cuales eran ingenieros distinguidos con décadas de experiencia, y tuve que explicar todo, desde las nociones más abstractas de interacción web hasta los detalles más finos de la sintaxis HTTP. Ese proceso perfeccionó mi modelo hasta convertirlo en un conjunto básico de principios, propiedades y restricciones que ahora se denominan REST. ^[7]

Propiedades arquitectónicas

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

• desempeño en las interacciones de los componentes, que puede ser el factor dominante en el desempeño percibido por el usuario y la eficiencia de la red; ^[9]
• escalabilidad que permite el soporte de una gran cantidad de componentes e interacciones entre componentes. Roy Fielding describe el efecto de REST sobre la escalabilidad de la siguiente manera:

  La separación de preocupaciones cliente-servidor de REST simplifica la implementación de componentes, reduce la complejidad de la semántica del conector, mejora la efectividad del ajuste del rendimiento y aumenta la escalabilidad de los componentes puros del servidor. Las restricciones del sistema en capas permiten intermediarios: proxies , puertas de enlace y firewalls- para ser introducido en varios puntos de la comunicación sin cambiar las interfaces entre los componentes, lo que les permite ayudar en la traducción de la comunicación o mejorar el rendimiento a través del almacenamiento en caché compartido a gran escala. REST permite el procesamiento intermedio al restringir los mensajes para que sean autodescriptivos: la interacción no tiene estado entre las solicitudes, los métodos estándar y los tipos de medios se utilizan para indicar la semántica y el intercambio de información, y las respuestas indican explícitamente la capacidad de almacenamiento en caché . ^[1]

• simplicidad de una interfaz uniforme;
• modificabilidad de los componentes para satisfacer las necesidades cambiantes (incluso mientras la aplicación se está ejecutando);
• visibilidad de la comunicación entre los 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 del sistema en presencia de fallas dentro de componentes, conectores o datos. ^[9]

Limitaciones arquitectónicas

Seis restricciones de orientación definen un sistema RESTful. ^{[8] [10]} Estas restricciones restringen las formas en que el servidor puede procesar y responder a las solicitudes de los clientes para que, al operar dentro de estas restricciones, el sistema obtenga propiedades no funcionales deseables , como rendimiento, escalabilidad, simplicidad, modificabilidad, visibilidad. , portabilidad y confiabilidad. ^[1] Si un sistema viola cualquiera de las restricciones requeridas, no se puede considerar RESTful.

Las restricciones formales de REST son las siguientes:

Arquitectura cliente-servidor

Ver también: Modelo cliente-servidor

El principio detrás de las restricciones cliente-servidor es la separación de preocupaciones. Separar las preocupaciones de la interfaz de usuario de las preocupaciones de almacenamiento de datos mejora la portabilidad de las interfaces de usuario en múltiples plataformas. También mejora la escalabilidad al simplificar los componentes del servidor. Quizás lo más significativo para la Web es que la separación permite que los componentes evolucionen de forma independiente, lo que respalda el requisito de escala de Internet de múltiples dominios organizacionales. ^[1]

Apatridia

Ver también: protocolo sin estado

En una interacción cliente-servidor, el estado se compone de un estado intrínseco y un estado extrínseco. El estado intrínseco, denominado estado de recursos , se almacena en el servidor y consta de información que es independiente del contexto del cliente, por lo que se puede compartir con todos los clientes del servidor. El estado extrínseco, llamado estado de la aplicación , se almacena en cada cliente y consiste en información que depende del contexto del cliente y, por lo tanto, no se puede compartir. Los clientes son responsables de pasar el estado de la aplicación al servidor cuando lo necesite. La restricción de almacenar el estado de la aplicación en el cliente en lugar de en el servidor hace que la comunicación no tenga estado. ^[11]

Capacidad de caché

Ver también: caché web

Al igual que en la World Wide Web, los clientes e intermediarios pueden almacenar en caché las respuestas. Las respuestas deben definirse, implícita o explícitamente, como almacenables en caché o no almacenables en caché para evitar que los clientes proporcionen datos obsoletos o inapropiados en respuesta a solicitudes posteriores. El almacenamiento en caché bien administrado elimina parcial o completamente algunas interacciones cliente-servidor, lo que mejora aún más la escalabilidad y el rendimiento.

Sistema en capas

Ver también: Sistema en capas

Normalmente, un cliente no puede saber si está conectado directamente al servidor final oa un intermediario en el camino. Si se coloca un proxy o un equilibrador de carga entre el cliente y el servidor, no afectará sus comunicaciones y no será necesario actualizar el código del cliente o del servidor. Los servidores intermedios pueden mejorar la escalabilidad del sistema al permitir el equilibrio de carga y al proporcionar cachés compartidos. Además, la seguridad se puede agregar como una capa sobre los servicios web, separando la lógica empresarial de la lógica de seguridad. ^[12] Agregar seguridad como una capa separada refuerza las políticas de seguridad . Finalmente, los servidores intermediarios pueden llamar a varios otros servidores para generar una respuesta al cliente.

Código a pedido (opcional)

Ver también: Secuencias de comandos del lado del cliente

Los servidores pueden ampliar o personalizar temporalmente la funcionalidad de un cliente transfiriendo código ejecutable: por ejemplo, componentes compilados como subprogramas de Java o scripts del lado del cliente como JavaScript .

Interfaz uniforme

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 limitaciones de esta interfaz uniforme son:

Identificación de recursos en solicitudes

Los recursos individuales se identifican en las solicitudes, por ejemplo, utilizando URI en los servicios web RESTful. 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 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, el tipo de medio puede especificar qué analizador invocar . ^[1]

Hipermedia como motor del estado de la aplicación ( HATEOAS )

Después de haber accedido a un URI inicial para la aplicación REST, análogo a un usuario web humano que 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 avanza el acceso, el servidor responde con un texto que incluye hipervínculos a otros recursos que están disponibles actualmente. No es necesario que el cliente esté codificado con información sobre la estructura o dinámica de la aplicación. ^[13]

Modelos de clasificación

Se han desarrollado varios modelos para ayudar a clasificar las API REST de acuerdo con su adherencia a varios principios del diseño REST, como el Modelo de Madurez de Richardson . ^[14]

Aplicado a los servicios web

Las API de servicios web que se adhieren a las restricciones de la arquitectura REST se denominan API RESTful. ^[15] Las API RESTful basadas en HTTP se definen con los siguientes aspectos: ^[16]

• un URI base , como http://api.example.com/;
• métodos HTTP estándar (por ejemplo, GET, POST, PUT y DELETE);
• un tipo de medio que define elementos de datos de transición de estado (por ejemplo, Atom, microformatos, application / vnd.collection + json, ^{[16] : 91–99,} etc.). La representación actual le dice al cliente cómo componer solicitudes de transiciones a todos los siguientes estados de aplicación disponibles. Esto podría ser tan simple como un URI o tan complejo como un subprograma de Java. ^[17]

Semántica de los métodos HTTP

La siguiente tabla muestra cómo los métodos HTTP deben usarse en las API HTTP, incluidas las RESTful.

Semántica de los métodos HTTP

Método HTTP	Descripción
OBTENER [3] : §4.3.1	Obtenga una representación del estado del recurso de destino.
POST [3] : §4.3.3	Deje que el recurso de destino procese la representación incluida en la solicitud.
PONER [3] : §4.3.4	Establezca el estado del recurso de destino en el estado definido por la representación incluida en la solicitud.
BORRAR [3] : §4.3.5	Elimina el estado del recurso de destino.

El método GET es seguro , lo que significa que aplicarlo a un recurso no da como resultado un cambio de estado del recurso (semántica de solo lectura). ^{[3] : §4.2.1} Los ^métodos GET, PUT y DELETE son idempotentes , lo que significa que aplicarlos varias veces a un recurso da como resultado el mismo cambio de estado del recurso que aplicarlos una vez, aunque la respuesta puede diferir. ^{[3] : §4.2.2} Los métodos GET y POST se pueden almacenar en caché , lo que significa que las respuestas a ellos pueden almacenarse para su reutilización futura. ^{[3] : §4.2.3}

Los métodos GET (leer), PUT (crear y actualizar) y DELETE (eliminar) son operaciones CRUD , ya que tienen semántica de administración de almacenamiento , lo que significa que permiten que los agentes de usuario manipulen directamente los estados de los recursos de destino. El método POST no es una operación CRUD, sino una operación de proceso que tiene una semántica específica de recursos de destino que excluye la semántica de gestión de almacenamiento, por lo que no permite que los agentes de usuario manipulen directamente los estados de los recursos de destino. ^{[3] : §4.3.3 [18]}

Discusión

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 hacen uso de 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). ^[17]

Ver también

• Atomicidad, consistencia, aislamiento, durabilidad (ACID)
• URL limpias
• Crear, leer, actualizar y eliminar (CRUD)
• Protocolo de aplicación de dominio (DAP)
• Microservicios
• Descripción general de los lenguajes de descripción de la API RESTful
  • Especificación OpenAPI (anteriormente Swagger): especificación para definir interfaces
  • OData - Protocolo para API REST
  • RAML
  • RSDL (lenguaje de descripción de servicio RESTful)
• Arquitectura orientada a recursos (ROA)
• Computación orientada a recursos (ROC)
• Arquitectura orientada a servicios (SOA)
• Arquitectura orientada a la web (WOA)

Referencias

1. Fielding, Roy Thomas (2000). "Capítulo 5: Transferencia de estado representacional (REST)" . Estilos arquitectónicos y diseño de arquitecturas de software basadas en redes (Ph.D.). Universidad de California, Irvine. Este capítulo presentó el estilo arquitectónico Representational State Transfer (REST) ​​para sistemas hipermedia distribuidos. REST proporciona un conjunto de restricciones arquitectónicas que, cuando se aplican en su conjunto, enfatizan la escalabilidad de las interacciones de los componentes, la generalidad de las interfaces, la implementación independiente de los componentes y los componentes intermedios para reducir la latencia de la interacción, reforzar la seguridad y encapsular los sistemas heredados.
2. "Arquitectura de servicios web" . Consorcio Mundial de la red. 11 de febrero de 2004. 3.1.3 Relación con la World Wide Web y las arquitecturas REST . Consultado el 29 de septiembre de 2016 .
3. Fielding, Roy (junio de 2014). "Protocolo de transferencia de hipertexto (HTTP / 1.1): Semántica y contenido, Sección 4" . IETF . Grupo de trabajo de ingeniería de Internet (IETF). RFC 7231 . Consultado el 14 de febrero de 2018 . 
4. "Fielding discutiendo la definición del término REST" . groups.yahoo.com . Consultado el 8 de agosto de 2017 .
5. Fielding, Roy; Gettys, Jim; Mogul, Jeffrey; Frystyk, Henrik; Maestro, Larry; Leach, Paul; Berners-Lee, Tim (junio de 1999). "Protocolo de transferencia de hipertexto - HTTP / 1.1" . IETF . Grupo de trabajo de ingeniería de Internet (IETF). RFC 2616 . Consultado el 14 de febrero de 2018 . 
6. Fielding, Roy Thomas (2000). "Capítulo 6: Experiencia y Evaluación" . Estilos arquitectónicos y diseño de arquitecturas de software basadas en redes (Ph.D.). Universidad de California, Irvine.Desde 1994, el estilo arquitectónico REST se ha utilizado para guiar el diseño y desarrollo de la arquitectura para la Web moderna. Este capítulo describe la experiencia y las lecciones aprendidas al aplicar REST al crear los estándares de Internet para el Protocolo de transferencia de hipertexto (HTTP) y los Identificadores uniformes de recursos (URI), las dos especificaciones que definen la interfaz genérica utilizada por todas las interacciones de componentes en la Web, como así como del despliegue de estas tecnologías en forma de la biblioteca cliente libwww-perl, el Proyecto del servidor HTTP Apache y otras implementaciones de los estándares del protocolo.
7. "Fielding analiza el desarrollo del estilo REST" . Tech.groups.yahoo.com. Archivado desde el original el 11 de noviembre de 2009 . Consultado el 14 de septiembre de 2014 .
8. Erl, Thomas; Carlyle, Benjamin; Pautasso, Cesare; Balasubramanian, Raj (2012). "5,1". SOA con REST: principios, patrones y restricciones para la creación de soluciones empresariales con REST . Upper Saddle River, Nueva Jersey: Prentice Hall. ISBN 978-0-13-701251-0.
9. Fielding, Roy Thomas (2000). "Capítulo 2: Arquitecturas de aplicaciones basadas en red" . Estilos arquitectónicos y diseño de arquitecturas de software basadas en redes (Ph.D.). Universidad de California, Irvine.
10. Richardson, Leonard; Ruby, Sam (2007). Servicios web RESTful . Sebastopol, California: O'Reilly Media. ISBN 978-0-596-52926-0.
11. "Fielding habla sobre los estados de la aplicación" . Tech.groups.yahoo.com . Consultado el 7 de febrero de 2013 .
12. Lange, Kenneth (2016). El pequeño libro sobre servicios REST . Copenhague. pag. 19 . Consultado el 18 de agosto de 2019 .
13. "DESCANSO HATEOAS" . RESTfulAPI.net.
14. Ivan Salvadori, Frank Siqueira (junio de 2015). "Un modelo de madurez para APIs web semánticas RESTful" . Conferencia: Servicios web (ICWS), Conferencia internacional IEEE 2015 sobre En: Nueva York - EE . UU. - a través de Researchgate.
15. "Qué es la API REST" . Tutorial de la API RESTful . Consultado el 29 de septiembre de 2016 .
16. Richardson, Leonard; Amundsen, Mike (2013), API web RESTful , O'Reilly Media, ISBN 978-1-449-35806-8
17. Roy T. Fielding (20 de octubre de 2008). "Las API REST deben estar impulsadas por hipertexto" . roy.gbiv.com . Consultado el 6 de julio de 2016 .
18. Roy T. Fielding (20 de marzo de 2009). "Está bien usar POST" . roy.gbiv.com . Consultado el 14 de abril de 2020 .

Lectura adicional

• Pautasso, Cesare; Wilde, Erik; Alarcón, Rosa (2014), REST: Temas de investigación avanzados y aplicaciones prácticas , Springer, ISBN 9781461492986
• Pautasso, Cesare; Zimmermann, Olaf; Leymann, Frank (abril de 2008), "RESTful Web Services vs. Big Web Services: Tomando la decisión arquitectónica correcta" , 17ª Conferencia Internacional World Wide Web (WWW2008)
• Ferreira, Otavio (noviembre de 2009), Semantic Web Services: A RESTful Approach , IADIS, ISBN 978-972-8924-93-5
• Fowler, Martin (18 de marzo de 2010). "Modelo de madurez de Richardson: pasos hacia la gloria del DESCANSO" . martinfowler.com . Consultado el 26 de junio de 2017 .