¿Alguien puede explicar "Hipertexto como motor del estado de la aplicación" en términos simples

Question

Este parece ser el principio de REST que he tenido el tiempo más difícil para entender. Entiendo que cuando designe un api de descanso la mayor parte del esfuerzo debería entrar en el diseño/descripción de hipertexto para la aplicación. ¿Alguna sugerencia para aplicaciones del mundo real de este principio? ¿Cómo aplica el protocolo átomo este principio? ¿Puede alguien explicar eso en términos simples cómo se aplicaría eso a una hipotética API de reposo de compras?

Answer 1

Considérese a sí mismo navegando en un sitio web normal. Cuando lo visita, lee los contenidos de las páginas y, según lo que ha leído y lo que quiere hacer, sigue varios enlaces en la página. Ese es realmente el núcleo de lo que "el hipertexto como motor del estado de la aplicación" se reduce a. En este ejemplo, el estado de la aplicación es el estado en su cabeza y la página en la que se encuentra. En función de eso, recorre más enlaces, lo que altera el estado de la aplicación en su cabeza.

Hay otro elemento en ello, la mente: la otra cara es que no debería necesitar adivinar esos URI: debería haber suficiente contexto en la página para inferir los URI (como la información que la aplicación tener del tipo de contenido, y cosas como la plantilla URI), o los URI a seguir deben estar presentes. Más allá de eso, una aplicación HTTP RESTful no debería preocuparse por la estructura de los URI.

ACTUALIZACIÓN: Para ampliar las cosas, los formularios HTML también demuestran HATEOAS. Las formas que usan GET son análogas al uso de plantillas URI. Y HATEOS no se limita a atravesar enlaces utilizando HTTP GET: formularios que usan POST (o algún otro método, si el navegador simplemente lo admite) puede describirse como una representación para enviar al servidor.

Answer 2

Este artículo proporciona algunas muestras en el contexto de Flickr.

Hypermedia in RESTful applications

Answer 3

Otra forma de ver este concepto es que el estado está representado por la página actual y los enlaces incrustados en ella. Atravesar un enlace cambia el estado de la aplicación que se representa en la página siguiente. Es un poco difícil de explicar ... los enlaces que están disponibles en cualquier momento definen qué acciones están disponibles en función de las acciones que ya se han producido. Esta es una definición de "estado actual".

El truco es representar las acciones disponibles que son URI que "actúan" en un recurso. La recuperación de la representación asociada con un URI lleva a cabo implícitamente la acción y recupera la representación resultante. Los URI están integrados en la representación y el usuario entiende la acción asociada con un URI específico. Los diversos métodos HTTP ayudan a definir las "acciones" que ocurren y especifica cuándo no se permite ninguna acción. Esto es a lo que la gente suele llegar cuando describe el paradigma RESTful completo.

Answer 4

Cuando intento explicar hypermedia, me gusta usar el ejemplo de navegar en un automóvil a través de señales frente a un mapa. Me doy cuenta de que no responde directamente a tu pregunta, pero puede ser útil.

Cuando conduce un automóvil y llega a una intersección en particular, se le proporcionan señales para indicar a dónde puede ir desde ese punto. Del mismo modo, hypermedia le proporciona un conjunto de opciones basadas en su estado actual.

Una API tradicional basada en RPC es más como un mapa. Con un mapa, usted tiende a planificar su ruta en función de un conjunto estático de datos de carreteras. Un problema con los mapas es que pueden quedar desactualizados y no proporcionan información sobre el tráfico u otros factores dinámicos.

La ventaja de los postes indicadores es que se pueden cambiar sobre la marcha para desviar el tráfico debido a la construcción o para controlar el flujo de tráfico.

No estoy sugiriendo que las señales sean siempre una mejor opción que un mapa. Obviamente, hay pros y contras, pero es valioso conocer ambas opciones. Es lo mismo con hypermedia. Es una alternativa valiosa a la interfaz RPC tradicional.