¿Qué tiene que ver "HATEOAS" con el estado de la solicitud?

HATEOAS es un acrónimo de "Hipermedia como el motor del estado de la aplicación". ¿A qué se refiere el "motor del estado de la aplicación" y, en particular, cómo es el "hipermedia" el motor del mismo?

Hasta donde he podido entender, HATEOAS, y los estándares asociados como HAL, abordan la parte de "descubrimiento" de REST.

La discusión de primavera al respecto se resume como:

Con HATEOAS, la salida facilita la tarea de comprender cómo interactuar con el servicio sin buscar una especificación u otro documento externo.

Lo que parece estar diciendo es que cuando realiza respuestas compatibles con HATEOAS, utilizando, por ejemplo, JSON compatible con HAL, el cliente no tiene que codificar ninguna ruta de recursos excepto la URL de la API raíz.

Lo cual tiene mucho sentido, excepto que parece no tener nada que ver con el "Estado de la aplicación". En el mejor de los casos, es con la Configuración del servidor (es decir, si cambio la URL de un recurso (Configuración del servidor), un consumidor aún puede averiguar dónde encontrarlo.

Elaborando un poco sobre lo que he podido deducir de lo que se trata HATEOAS, existe este extracto de la misma página de descripción. Lo que se muestra es que HATEOAS resolvió el problema de descubrir dónde están los recursos. Pero no parece estar relacionado con el "Estado de la aplicación" ...

Una presentación JSON simple se representa tradicionalmente como:

{ 
    "name" : "Alice"
}

Los datos del cliente están allí, pero los datos no contienen nada sobre sus enlaces relevantes.

Una respuesta basada en HATEOAS se vería así:

{
    "name": "Alice",
    "links": [ {
        "rel": "self",
        "href": "http://localhost:8080/customer/1"
    } ]
}

Esta respuesta no solo tiene el nombre de la persona, sino que incluye la URL de enlace automático donde se encuentra esa persona.

Una aplicación web, RESTful o no, generalmente no es simplemente un servicio de datos; expone varios recursos y proporciona algo de comportamiento, por lo que tiene estado; Se hace una distinción entre el estado del recurso (independiente del cliente, administrado por la aplicación) y el estado de la aplicación , que es específico del cliente. Una aplicación sin estado no almacena el estado de la aplicación (específica del cliente); en cambio, permite que el cliente sea responsable de la misma, y proporciona una API que permite la transferencia (aplicación) de vuelta estado y vuelta (por lo tanto " S tate T ransferencia" en RE ST) Desde la perspectiva de un cliente, una aplicación web es una máquina de estado, que reside detrás de una API que permite la interacción, pero parte del estado se proporciona como información contextual por parte de los clientes, para complementar las solicitudes.

Ahora, mientras estudiaba REST, es posible que se haya topado con algo llamado El Modelo de Madurez Richardson- describe la "madurez" de una API de aplicación web (que evoluciona con los años), pero es útil para nosotros como una especie de referencia que pone las cosas en contexto. En este modelo, todos los niveles de madurez, excepto el último, proporcionan esencialmente API que facilitan los RPC a través de HTTP. En este estilo de diseño de API, HTTP se utiliza como mecanismo de transporte, pero la comunicación real se realiza a través de protocolos personalizados, por lo que los sistemas que interactúan (clientes y la aplicación) dependen de la llamada "información fuera de banda" para comunicarse (en este caso contexto, esto solo significa que estos sistemas se comunican utilizando algún estándar personalizado en lugar de aprovechar hipertexto / hipermedia y, por ejemplo, el protocolo HTTP existente). Entonces, lo que impulsa la transferencia de estado y las transiciones de estado ("el motor del estado de la aplicación") no es hipermedia en este caso.

El nivel de madurez final introduce la restricción HATEOAS, y solo entonces la API se vuelve RESTful. El cliente inicia la interacción a través del URI inicial; el servidor responde con una representación adecuada basada en hipermedia del estado de la aplicación (que puede diferir entre dispositivos o clientes, o debido a varias condiciones, por lo tanto, " Re presentacional" en RE ST), que incluye acciones de autodescripción que permiten al cliente iniciar la siguiente transición de estado (por lo que hipermedia es ahora lo que admite y controla directamente el estado de la aplicación).

¿Puedo retomar la afirmación de que "el estado de la aplicación es específico del cliente". Así es como lo entiendo. [...] Tiene que ver con la disponibilidad de recursos del lado del servidor, nada (aparente que pueda ver) que ver con el estado del cliente ...

Permítanme primero asegurarme de que estamos en la misma página. Este no es el estado del cliente (como en el estado interno del propio cliente), sino el estado de la aplicación web que es particular de un cliente específico.

El ejemplo que menciona realmente no lo ilustra bien, pero la lista de enlaces devuelta se genera esencialmente de forma dinámica en el servidor y representa las transiciones de estado disponibles actualmente, y como tal, codifica el estado actual de la aplicación (para ese cliente en particular). Tenga en cuenta que puede optar por transferir otros bits de información relacionada con el estado (en ambas direcciones) si su aplicación lo requiere (por lo que no está limitado a los metadatos de transición de estado), pero la restricción es no recordar nunca ningún dato específico del cliente en el servidor, porque eso perjudica la comerciabilidad. Tenga en cuenta también que este estado no tiene que ser completo (no tiene que ser completamente significativo cuando lo mira de forma aislada), pero debe ser suficiente para que la parte receptora tome una decisión y realice una lógica basada en él y nada más (entonces,

HATEOAS aprovecha la interfaz uniforme (los estándares comunes y los formatos de intercambio de datos) para desacoplar a los clientes y servidores para que en el lado del servidor puedan barajar las cosas detrás del "contrato" definido por el tipo hipermedia, pero también porque la comunicación se basa en La información fuera de banda (protocolos personalizados) a menudo no aprovecha la infraestructura de red de una manera que REST pretende hacer. (Vea la discusión a continuación).

En su ejemplo, el cliente no basaría su lógica en el URI, sino en metadatos (o anotaciones), como el atributo "rel". Por ejemplo, a un navegador no le importan los URI en los enlaces, solo necesita saber qué tipo de enlace es (un enlace en el que se puede hacer clic, un formulario desde el que puede construir un URI, una referencia de hoja de estilo, etc.)

RESTO en contexto

Desafortunadamente, REST se ha convertido en una palabra de moda, y todo el mundo está hablando sobre cómo ser RESTful, pero falta todo el contexto de REST, y no se puede entender el estilo arquitectónico REST sin entender este contexto (¿cuál es el problema de que REST es realmente tratando de resolver)

REST es una generalización de la arquitectura detrás de la Web . Para la mayoría de nosotros, la Web es una plataforma. Pero para las personas que desarrollaron REST, WWW es una aplicación , que tiene un cierto conjunto de requisitos, que se ejecuta en una red mundial. Por lo tanto, REST está destinado a sistemas que son como la Web en algunos aspectos importantes, que necesitan satisfacer un cierto conjunto de propiedades.

Estos son sistemas en red a gran escala que tienen una larga vida (piense décadas). Estos son sistemas que abarcan límites organizacionales (por ejemplo, empresas colaboradoras), o límites entre diferentes subentidades en una organización grande (como diferentes divisiones e incluso equipos). Aunque existe colaboración, todas las entidades involucradas operan en gran medida (trabajan y desarrollan e implementan software) en sus propios términos, a su propio ritmo, con sus propios problemas de seguridad, y todos usan diferentes dispositivos, sistemas operativos, etc. necesitan acceder y compartir referencias a los recursos de cada uno (documentos, servicios, datos), al tiempo que pueden evolucionar de forma independiente e incremental, sin tener que hacer una coordinación extensa (diablos, es difícil lograr que las personas realicen un despliegue coordinado incluso dentro de la misma organización).

Aquellos que brindan servicios deben poder hacer cosas como desarrollar versiones de servicio, agregar nodos o mezclar datos con un efecto mínimo en los clientes. Necesitan escalar. Los clientes (que pueden ser servicios) deben seguir trabajando a pesar de toda esta actividad en el lado del servidor. Es probable que los sistemas se utilicen de manera imprevista en el futuro. Los recursos a los que acceden e intercambian pueden ser de muchos tipos diferentes y realizarse (codificados, mecanografiados, representados, estructurados) internamente (por proveedores de servicios) de muchas maneras diferentes, pero aun así, para el sistema / red en general, es una forma consistente de se requiere acceso a recursos y estructura de datos y respuestas (interfaz uniforme).

REST tiene todo esto en cuenta y tiene muy en cuenta las propiedades de la red. Su objetivo es abordar las necesidades de las aplicaciones que son, en un alto nivel (dentro de su propio dominio comercial), similares en términos de requisitos y limitaciones a lo que se describe anteriormente (o aspira a ser).

Y lo hace, pero no es una panacea. Hay costos y compensaciones. Impone un cierto estilo de comunicación, y hay un éxito en el rendimiento. Siempre está transfiriendo datos de manera general, a menudo los mismos datos repetidamente, en un formato generalizado (y, por lo tanto, puede que no sea el más eficiente para su servicio), con un montón de metadatos, a menudo a través de nodos de red intermedios ( por lo tanto, todo el almacenamiento en caché en la Web: minimiza el envío de datos de un lado a otro, manteniendo al cliente alejado del servicio cuando sea posible). El rendimiento percibido por el usuario es importante, lo que afecta la forma en que escribe clientes (es por eso que los navegadores comienzan a mostrar la página antes de que todo esté descargado o listo). Pero felizmente paga ese costo para poder construir un sistema con las propiedades descritas anteriormente.

Por el contrario, si está creando un sistema que tiene diferentes requisitos / restricciones, el costo puede no valer la pena.

Si desea comprender REST, o HATEOAS, probablemente debería comenzar por comprender la web . HAL es (efectivamente) solo un sustituto de HTML; si comprende cómo "funciona" HTML, entonces comprender el papel de HAL es mucho más fácil.

¿A qué se refiere el "Motor del estado de aplicación"?

Capítulo 5 de la tesis de Fielding .

REST está definido por cuatro restricciones de interfaz: identificación de recursos; manipulación de recursos a través de representaciones; mensajes autodescriptivos; e hipermedia como motor del estado de la aplicación. - Interfaz uniforme

Por lo tanto, el estado de una aplicación se define por sus solicitudes pendientes, la topología de los componentes conectados (algunos de los cuales pueden estar filtrando datos almacenados en el búfer), las solicitudes activas en esos conectores, el flujo de datos de las representaciones en respuesta a esas solicitudes y el procesamiento de esas representaciones tal como las recibe el agente de usuario. - Vista de datos

Por lo tanto, la aplicación modelo es un motor que se mueve de un estado a otro al examinar y elegir entre las transiciones de estado alternativas en el conjunto actual de representaciones. No es sorprendente que esto coincida exactamente con la interfaz de usuario de un navegador hipermedia. Sin embargo, el estilo no supone que todas las aplicaciones sean navegadores. De hecho, la interfaz del conector genérico oculta los detalles de la aplicación del servidor y, por lo tanto, un agente de usuario podría ser igualmente un robot automatizado que realiza la recuperación de información para un servicio de indexación, un agente personal que busca datos que coincidan con ciertos criterios o un mantenimiento araña ocupada patrullando la información para referencias rotas o contenido modificado - Vista de datos

Considere cómo funciona la búsqueda de Google: utiliza un marcador para actualizar su copia almacenada localmente del formulario de búsqueda, carga el formulario, escribe su consulta en el formulario, lo envía y lee los resultados. Nada de eso necesitaba ninguna capacidad de Google integrada en el cliente; todo utiliza capacidades de HTML; los metadatos incluidos con el formulario le dicen al navegador (a través de reglas de procesamiento estandarizadas) cómo construir una solicitud HTTP que devolverá una representación del recurso descansado (también conocido como los resultados de búsqueda).

HAL juega el mismo papel: un cliente con conocimiento de HAL puede aplicar las reglas de procesamiento para descubrir enlaces en las representaciones y hacer cosas inteligentes con esos enlaces. Un cliente compatible con JSON no puede, porque no hay nada en el modelo de procesamiento JSON que defina un enlace.