Qualcuno può spiegare "Hypertext come motore dello stato dell'applicazione" in termini semplici

Question

Questo sembra essere il principale REST che ho avuto il tempo più difficile che mi avvolge la testa. Capisco che quando si designa una pausa la maggior parte dello sforzo dovrebbe andare a progettare/descrivere l'ipertesto per l'applicazione.Qualsiasi puntatore alle applicazioni del mondo reale di questo principale? Come si applica il protocollo atom questo principio? Qualcuno può spiegare che, in termini semplici, come si applicherebbe a un ipotetico carrello di riposo.

Answer 1

Considera di navigare su un normale sito web. Quando visiti, leggi i contenuti delle pagine e, in base a ciò che hai letto e ciò che vuoi fare, segui vari link sulla pagina. Questo è davvero il nucleo di ciò che "l'ipertesto come motore dello stato dell'applicazione" si riduce a. In questo esempio, lo stato dell'applicazione è lo stato nella tua testa e nella pagina in cui ti trovi. Sulla base di ciò, si attraversano ulteriori collegamenti, che alterano lo stato dell'applicazione nella propria testa. C'è un altro elemento, mente: l'altro lato è che non dovresti aver bisogno di indovinare quegli URI: ci dovrebbe essere abbastanza contesto nella pagina per dedurre gli URI (come le informazioni che l'applicazione avrebbe devono avere il tipo di contenuto e cose come il modello URI) o dovrebbero essere presenti gli URI da seguire. Oltre a ciò, un'applicazione HTTP RESTful non dovrebbe preoccuparsi della struttura degli URI.

AGGIORNAMENTO: Per espandere le cose, i moduli HTML dimostrano anche HATEOAS. I moduli che utilizzano GET sono analoghi all'uso di modelli URI. E HATEOS non si limita semplicemente al passaggio dei link usando HTTP GET: i moduli che usano il POST (o qualche altro metodo, se il browser semplicemente lo supporta) possono rappresentare una descrizione da inviare al server.

Answer 2

Questo articolo fornisce alcuni campioni nel contesto di Flickr.

Hypermedia in RESTful applications

Answer 3

Un altro modo per osservare questo concetto è che lo stato è rappresentato dalla pagina corrente e dai collegamenti incorporati. Attraversare un collegamento cambia lo stato dell'applicazione che è rappresentata dalla pagina successiva. È un po 'difficile da spiegare ... i collegamenti disponibili in qualsiasi momento definiscono quali azioni sono disponibili in base alle azioni che sono già avvenute. Questa è una definizione di "lo stato attuale".

Il trucco è quello di rappresentare le azioni disponibili sono gli URI che "agiscono" su una risorsa. Il recupero della rappresentazione associata a un URI esegue implicitamente l'azione e recupera la rappresentazione risultante. Gli URI sono incorporati nella rappresentazione e l'utente comprende l'azione associata a un URI specifico. I vari metodi HTTP aiutano a definire le "azioni" che si verificano e specifica quando nessuna azione è consentita. Questo è di solito ciò a cui le persone arrivano quando descrivono l'intero paradigma RESTful.

Answer 4

Quando si tenta di spiegare l'ipermedia, mi piace utilizzare l'esempio della navigazione in un'auto tramite i cartelli rispetto a una mappa. Mi rendo conto che non risponde direttamente alla tua domanda ma potrebbe essere d'aiuto.

Quando si guida un'auto e si raggiunge un particolare incrocio, vengono fornite indicazioni per indicare dove si può andare da quel punto. Allo stesso modo, hypermedia ti offre un insieme di opzioni basate sul tuo stato attuale.

Un'API tradizionale basata su RPC è più simile a una mappa. Con una mappa si tende a pianificare il percorso in base a un set statico di dati stradali. Un problema con le mappe è che possono diventare obsolete e non forniscono informazioni sul traffico o altri fattori dinamici.

Il vantaggio dei pannelli è che possono essere modificati al volo per deviare il traffico a causa di lavori di costruzione o per controllare il flusso del traffico.

Non sto suggerendo che le indicazioni sono sempre un'opzione migliore di una mappa. Ovviamente ci sono pro e contro ma è importante essere consapevoli di entrambe le opzioni. È lo stesso con hypermedia. È una valida alternativa alla tradizionale interfaccia RPC.