In REST HATEOAS parla davvero di auto-scoperta o di navigazione? [duplicare]

Dichiarazione di non responsabilità: risposta offerta senza prima rileggere la Tesi sul campo .

HATEOAS supporta la scoperta di stati di applicazione precedentemente sconosciuti.

Think state machine. La rappresentazione hypermedia inviata all'applicazione descrive uno stato corrente dell'applicazione e descrive quali trigger sono transizioni valide fuori dallo stato.

Non descrive necessariamente come implementare il trigger.

Come al solito, considera il web come l'esempio di Ur. Inizi la tua applicazione di Wikipedia indirizzando il browser alla pagina di destinazione e tre ore dopo ti ritrovi a leggere su Tassonomia degli agrumi .

Come succede? Wikipedia invia una descrizione ipermedia (text / html) dello stato dell'applicazione (la pagina di destinazione); inclusi nell'ipermedia sono link (tag di ancoraggio). L'applicazione (browser) sa cosa fare con quelli perché l'implementazione è stata scritta con consapevolezza delle specifiche html.

Quando scriviamo html conforme a una nuova versione della specifica, l'ipermedia non dice ai vecchi browser come implementarlo - Netscape 2.0 non "scopre" magicamente come implementare il video incorporato in html5.

In generale, il documento ipermedia fornisce i trigger supportati, ma si presume che il client ignori eventuali trigger che non riconosce. Le definizioni degli stessi trigger sono fuori banda.

So, is HATEOAS about discovering how to use a RESTful web service or is it really about navigation?

Considera un libro "Scegli la tua avventura".

To visit the Cave of Wonders, turn to page 17.

Il libro ti dice come navigare nelle pagine o ti sta dicendo come scoprire la storia?

@ La risposta di VoiceOfUnreason suggerisce che HATEOAS si riferisce solo ai collegamenti. Tuttavia, la domanda Programmers StackExchange @RobertHarvey collegata a Che cosa offre HATEOAS per la scopribilità e il disaccoppiamento oltre alla possibilità di modificare la struttura dell'URL più o meno liberamente? , suggerisce che è più complicato di così, e HATEOAS include entrambi utilizzando il metodo OPTIONS per determinare quali metodi possono essere chiamato su una risorsa e definire un tipo di supporto per specificare il formato dei dati nella richiesta e la risposta.

Una delle risposte a questa domanda ("Cosa offre HATEOAS ...") include un link a un post sul blog di Roy Fielding, che in origine ha definito REST: Le API REST devono essere guidate da un ipertesto . Alcuni frammenti di quel post del blog:

A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]

A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC’s functional coupling].

A REST API should never have “typed” resources that are significant to the client. Specification authors may use resource types for describing server implementation behind the interface, but those types must be irrelevant and invisible to the client. The only types that are significant to a client are the current representation’s media type and standardized relation names. [ditto]

A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]

(Per inciso: ho l'impressione da molti post sul blog che molte persone vedono HATEOAS come una sorta di extra opzionale per REST.Tuttavia, i commenti di Roy Fielding citati sopra indicano che HATEOAS è in realtà centrale per REST e tu puoi ' t avere un'API RESTful senza di essa.)

Se qualcuno trova utile questa risposta, per favore, aumenta il commento di @ RobertHarvey alla mia domanda sopra, quella che ha il link "Che cosa offre HATEOAS ...".