¿Cuál es el beneficio de hipermedia (HATEOAS)?

No entiendo el beneficio de HATEOAS para las API destinadas a ser utilizadas por programas (a diferencia de los humanos que navegan directamente por su API). Claro, el cliente no está vinculado a un esquema de URL, pero sí a un esquema de datos que es lo mismo en mi mente.

Por ejemplo, suponga que quiero ver un artículo en un pedido, supongamos que descubrí o conozco la URL del pedido.

HATEOAS

order = get(orderURL);
item = get(order.itemURL[5]);

no HATEOAS:

order = get(orderURL);
item = get(getItemURL(order,5));

En el primer modelo tengo que saber el hecho de que el objeto de orden tiene un campo itemURL. En el segundo modelo, tengo que saber cómo construir una URL de elemento. En ambos casos tengo que "saber" algo antes de tiempo, entonces, ¿qué está haciendo realmente HATEOAS por mí?

web-development rest

— Paso
fuente

get(orderURL);debería estar diciendo the fact that the order object has an itemURL field.

— Yannis

Cuando escribe la aplicación cliente, debe saber de antemano cuál es el campo.

— Paso

No, ese es el punto principal de HATEOAS, no tiene que saber de antemano cuál es el campo, solo necesita unos pocos puntos estándar establecidos y el resto se puede descubrir. "El principio es que un cliente interactúa con una aplicación de red completamente a través de hipermedios proporcionados dinámicamente por servidores de aplicaciones. Un cliente REST no necesita conocimiento previo sobre cómo interactuar con una aplicación o servidor en particular más allá de una comprensión genérica de hipermedia".

— Yannis

¿Cómo se supone que una aplicación obtiene el artículo de un pedido si la aplicación ni siquiera sabe que un pedido tiene un artículo? Discovery funciona para la exploración manual pero no para aplicaciones automatizadas.

— Pace

El hombre mismo está hablando aquí: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

— Thiago Silva

Respuestas:

Una diferencia es que el esquema es un estándar, o al menos puede ser reutilizado por otros.

Por ejemplo, supongamos que está utilizando la API de Twitter y también desea admitir StatusNet (o en su lugar). Como usan el mismo modelo de datos que Twitter, si la API sigue a HATEOAS, ahora solo tiene que cambiar la URL principal. Si no es así, ahora debe cambiar cada URL del código.

Por supuesto, si necesita cambiar el código para poner la URL del punto de entrada del servicio de todos modos, puede no parecerle tan útil. Realmente brilla si esa URL se inserta dinámicamente; por ejemplo, si estuviera creando un servicio como Twillio, que interactuaría con la propia API del usuario.

— André Paramés
fuente

Ese es un punto interesante que no había considerado.

— Paso

@ YannisRizos: Hmm, no veo dónde dije que HATEOAS es un estándar. Dije que el " esquema (de datos) es un estándar". En la terminología REST, ese sería el tipo de medio.

— André Paramés

En la segunda lectura, tienes toda la razón.

— Yannis

Sí, si asume que los nombres rel para los enlaces son los mismos. Pero hablando en general, y no solo en el ejemplo específico que mencionas, cada programador en el mundo no necesariamente elegirá los mismos nombres para acciones similares o equivalentes. Este beneficio proviene de que los programadores acuerdan una denominación y parámetros de interfaz comunes.

— derloopkat

API explorable: puede sonar trivial pero no subestime el poder de una API explorable. La capacidad de navegar alrededor de los datos hace que sea mucho más fácil para los desarrolladores del cliente construir un modelo mental de la API y sus estructuras de datos.
Documentación en línea: el uso de URL como relaciones de enlace puede dirigir a los desarrolladores del cliente a la documentación.
Lógica de cliente simple: un cliente que simplemente sigue las URL en lugar de construirlas por sí mismo, debería ser más fácil de implementar y mantener.
El servidor toma posesión de las estructuras de URL: el uso de hipermedia elimina el conocimiento codificado por el cliente de las estructuras de URL utilizadas por el servidor.
Descarga de contenido a otros servicios: Hypermedia es necesario cuando se descarga contenido a otros servidores (un CDN por ejemplo).
Control de versiones con enlaces: Hypermedia ayuda al control de versiones de las API.
Implementaciones múltiples del mismo servicio: Hypermedia es una necesidad cuando existen implementaciones múltiples del mismo servicio (y un cliente necesita acceder a más de uno de ellos).

Puede encontrar una explicación detallada de estos puntos aquí: http://soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html

— Jørn Wildt
fuente

> Descarga de contenido a otros servicios: Hypermedia es necesario cuando se descarga contenido a otros servidores (un CDN por ejemplo). No, no es. Puede mantener los mismos enlaces y usar CDN.

— Bruno Costa