Qual è il vantaggio di hypermedia (HATEOAS)?

Non capisco il vantaggio di HATEOAS per le API destinate all'uso da parte dei programmi (al contrario degli umani che navigano direttamente nella tua API). Certo, il cliente non è vincolato a uno schema URL ma è legato a uno schema di dati che è la stessa cosa nella mia mente.

Ad esempio, supponiamo di voler visualizzare un articolo su un ordine, supponiamo di aver già scoperto o di conoscere l'URL dell'ordine.

hateoas:

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

non hateoas:

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

Nel primo modello devo sapere che l'oggetto ordine ha un campo itemURL. Nel secondo modello devo sapere come costruire un URL elemento. In entrambi i casi devo "sapere" qualcosa in anticipo, quindi cosa sta facendo effettivamente HATEOAS per me?

web-development rest

— Ritmo
fonte

get(orderURL);dovrei dirtelo the fact that the order object has an itemURL field.

— yannis,

Quando scrivi l'applicazione client devi sapere in anticipo quale sia il campo.

— Pace,

No, questo è il punto principale di HATEOAS, non devi sapere in anticipo quale sia il campo, hai bisogno solo di alcuni punti standard impostati e il resto è rilevabile. "Il principio è che un client interagisce con un'applicazione di rete interamente tramite hypermedia fornito dinamicamente dai server delle applicazioni. Un client REST non ha bisogno di conoscenze preliminari su come interagire con una particolare applicazione o server oltre una comprensione generica dell'hypermedia."

— yannis,

In che modo un'applicazione dovrebbe ottenere l'articolo da un ordine se l'applicazione non sa nemmeno che un ordine ha un articolo? Il rilevamento funziona per la navigazione manuale ma non per le applicazioni automatizzate.

— Pace

L'uomo stesso ne parla qui: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

— Thiago Silva,

Risposte:

Una differenza è che lo schema è, si spera, uno standard, o almeno può essere riutilizzato da altri.

Ad esempio, supponiamo che tu stia utilizzando l'API di Twitter e desideri supportare anche StatusNet (o invece). Poiché utilizzano lo stesso modello di dati di Twitter, se l'API segue HATEOAS ora devi solo modificare l'URL principale. In caso contrario, ora è necessario modificare ogni singolo URL dal codice.

Naturalmente, se è necessario modificare il codice per inserire comunque l'URL del punto di ingresso del servizio, potrebbe non sembrare così utile. Brilla davvero se l'URL viene inserito in modo dinamico; ad esempio, se stavi costruendo un servizio come Twillio, che avrebbe interagito con l'API dell'utente.

— André Paramés
fonte

Questo è un punto interessante che non avevo considerato.

— Pace,

@YannisRizos: Hmm, non vedo dove ho detto che HATEOAS è uno standard. Ho detto che "lo schema (dei dati) si spera sia uno standard". Nella terminologia REST, sarebbe il tipo di supporto.

— André Paramés,

In seconda lettura, hai assolutamente ragione.

— yannis,

Sì, se si assume che i nomi rel per i collegamenti siano gli stessi. Ma parlando in generale, e non solo sull'esempio specifico che menzioni, ogni programmatore nel mondo non necessariamente sceglierà gli stessi nomi per azioni simili o equivalenti. Questo vantaggio deriva dal fatto che i programmatori concordano una denominazione e parametri dell'interfaccia comuni.

— derloopkat,

API esplorabili: può sembrare banale ma non sottovalutare la potenza di un'API esplorabile. La possibilità di navigare tra i dati rende molto più semplice per gli sviluppatori client la creazione di un modello mentale dell'API e delle sue strutture di dati.
Documentazione incorporata: l'uso di URL come relazioni di collegamento può indirizzare gli sviluppatori client alla documentazione.
Logica client semplice: un client che segue semplicemente gli URL invece di costruirli da soli, dovrebbe essere più facile da implementare e gestire.
Il server diventa proprietario delle strutture URL: l'uso di hypermedia rimuove la conoscenza codificata del client delle strutture URL utilizzate dal server.
Scarico del contenuto su altri servizi: Hypermedia è necessario quando si scarica il contenuto su altri server (ad esempio un CDN).
Controllo delle versioni con collegamenti: Hypermedia aiuta il controllo delle versioni delle API.
Implementazioni multiple dello stesso servizio: Hypermedia è una necessità quando esistono implementazioni multiple dello stesso servizio (e un client deve accedere a più di uno di essi).

Puoi trovare una spiegazione approfondita di questi punti elenco qui: http://soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html

— Jørn Wildt
fonte

> Scarico del contenuto su altri servizi: Hypermedia è necessario quando si scarica il contenuto su altri server (ad esempio un CDN). No non lo è. Puoi semplicemente mantenere gli stessi collegamenti e utilizzare CDN.

— Bruno Costa,