Connectedness & HATEOAS

Question

Se dice que en un sistema RESTful bien definido, los clientes solo necesitan conocer el URI raíz o algunos pocos URI conocidos y el cliente descubrirá todos los demás enlaces a través de estos URI iniciales. Hago entender los beneficios (clientes desconectados) de este enfoque, pero el inconveniente para mí es que el cliente necesita para descubrir los vínculos cada vez que intenta acceder a algo es decir, teniendo en cuenta la siguiente jerarquía de los recursos:

/collection1 
collection1 
    |-sub1 
    |-sub1sub1 
|-sub1sub1sub1 
     |-sub1sub1sub1sub1 
    |-sub1sub2 
    |-sub2 
    |-sub2sub1 
    |-sub2sub2 
    |-sub3 
    |-sub3sub1 
    |-sub3sub2 

Si seguimos el cliente "solo necesita conocer el URI raíz", entonces un cliente solo debe conocer el URI raíz ie/collection1 anterior y el resto de los URI deben ser descubiertos por los clientes a través de hipermedia links. Me resulta engorroso porque cada vez que un cliente necesita hacer un GET, por ejemplo en sub1sub1sub1sub1, el cliente primero debe hacer un GET on/collection1 y el siguiente enlace definido en la representación devuelta y luego hacer varios GET adicionales en los sub recursos para alcanzar el recurso deseado? o es mi comprensión sobre la conexión completamente incorrecta?

Saludos, Suresh

Answer 1

Se encontrará con esta discrepancia cuando intente crear una API REST que no coincida con el flujo del agente de usuario que está consumiendo la API.

Considere cuando ejecuta una aplicación cliente, siempre se le presenta al usuario alguna pantalla inicial. Si combina el contenido y las opciones en esta pantalla con la representación raíz, los enlaces disponibles y las transiciones deseadas coincidirán muy bien. A medida que el usuario selecciona las opciones en la pantalla, puede hacer la transición a otras representaciones y la IU del cliente debe actualizarse para reflejar la nueva representación.

Si intenta modelar su REST API como un tipo de repositorio de datos vinculado y su UI de cliente como un conjunto independiente de transiciones, entonces encontrará HATEOAS bastante doloroso.

Answer 2

no creo que ese es el requisito estricto. Por lo que entiendo, es legal que un cliente acceda a los recursos directamente y comience desde allí. Lo importante es que no haga esto para las transiciones de estado, es decir, no proceda automáticamente con/foo2 después de operar en/foo1, etc. Recuperando/products/1234 inicialmente para editar parece perfectamente bien. El servidor siempre puede devolver, por ejemplo, una redirección a/shop/products/1234 para seguir siendo compatible con versiones anteriores (lo cual es deseable para los motores de búsqueda, los marcadores y los enlaces externos también).

Answer 3

Sí, es correcto que la aplicación cliente atraviese los enlaces, pero una vez que se descubre un recurso, no hay nada de malo en mantener una referencia a ese recurso y usarlo durante más tiempo que una solicitud. Si su cliente tiene la posibilidad de recordar cosas permanentemente, puede hacerlo.

considere cómo un navegador web mantiene sus marcadores. Probablemente tengas quizás diez o cien marcadores en el navegador, y probablemente encuentres algunos de ellos en una jerarquía de páginas, pero el navegador los recuerda diligentemente sin necesidad de recordar el camino que tomó encontrarlos.

Una aplicación cliente más completa podría recordar el URI de sub1sub1sub1sub1 y volver a utilizarlo si aún funciona. Es probable que todavía represente lo mismo (debería). Si ya no existe o falla por algún otro motivo del cliente (4xx) puede volver sobre sus pasos para ver si puede encontrar un reemplazo adecuado.

Y, por supuesto, lo que Darrel Miller dijo :-)