stringtranslate.com

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]

Principio

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.

Historia

Roy Fielding hablando en OSCON 2008

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 "Estilos arquitectónicos y el diseño de arquitecturas de software basadas en red" [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 .

Propiedades arquitectónicas

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.

Un modelo entidad-relación de los conceptos expresados ​​en el estilo arquitectónico REST

Las restricciones del estilo arquitectónico REST afectan las siguientes propiedades arquitectónicas: [1] [6]

Restricciones arquitectónicas

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]

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 restricciones para esta interfaz uniforme son:

Modelos de clasificación

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

Véase también

Referencias

  1. ^ abcdef 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. Archivado desde el original el 13 de mayo de 2021. Consultado el 17 de agosto de 2004 .
  2. ^ Fielding, Roy T. (2008-10-20). "Las API REST deben estar basadas en hipertexto". roy.gbiv.com. Archivado desde el original el 2010-03-18 . Consultado el 2016-07-06 .
  3. ^ Couldry, Nick (2012). Medios, sociedad y mundo: teoría social y práctica de los medios digitales. Londres: Polity Press. p. 2. ISBN 9780745639208Archivado desde el original el 27 de febrero de 2024. Consultado el 9 de junio de 2021 .
  4. ^ ab 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. Archivado desde el original el 26 de marzo de 2023. Consultado el 21 de junio de 2023 .
  5. ^ "Fielding analiza la definición del término REST". groups.yahoo.com. Archivado desde el original el 5 de noviembre de 2015. Consultado el 8 de agosto de 2017 .
  6. ^ ab Erl, Thomas; Carlyle, Benjamin; Pautasso, Cesare; Balasubramanian, Raj (2012). "5.1". SOA con REST: principios, patrones y restricciones para crear soluciones empresariales con REST . Upper Saddle River, Nueva Jersey: Prentice Hall. ISBN 978-0-13-701251-0.
  7. ^ ab Fielding, Roy Thomas (2000). "Capítulo 2: Arquitecturas de aplicaciones basadas en redes". Estilos arquitectónicos y diseño de arquitecturas de software basadas en redes (Ph.D.). Universidad de California, Irvine. Archivado desde el original el 16 de diciembre de 2014. Consultado el 12 de abril de 2014 .
  8. ^ Richardson, Leonard; Ruby, Sam (2007). Servicios web RESTful . Sebastopol, California: O'Reilly Media. ISBN 978-0-596-52926-0.
  9. ^ "¿Qué es la API REST?". www.visual-paradigm.com . Archivado desde el original el 24 de febrero de 2024 . Consultado el 24 de febrero de 2024 .
  10. ^ Gupta, Lokesh (2 de junio de 2018). "REST HATEOAS". Tutorial de API REST . RESTfulAPI.net. Archivado desde el original el 7 de abril de 2019 . Consultado el 10 de marzo de 2019 .
  11. ^ "Clasificación de las API HTTP". algermissen.io . Archivado desde el original el 2023-01-29 . Consultado el 2023-01-29 .
  12. ^ Ivan Salvadori, Frank Siqueira (junio de 2015). "Un modelo de madurez para las API web semánticas RESTful". Conferencia: Servicios web (ICWS), 2015 IEEE International Conference OnAt . Nueva York. Archivado desde el original el 2024-02-27 . Consultado el 14 de diciembre de 2020 a través de Researchgate.


Lectura adicional