Esempi reali di HATEOAS (architettura REST) ​​[chiuso]


140

come tutti hanno notato, ci sono molte API REST false / rudimentali in natura (che implementano un'API HTTP e la chiamano REST senza seguire il requisito ipertesto come motore dello stato dell'applicazione, che ha portato al famoso rant di Roy T. Fielding , l'uomo che per primo ha specificato il paradigma REST).

Non sono stato in grado di trovare esempi pratici di un'implementazione REST guidata dall'ipertesto, insieme alle definizioni associate al tipo di supporto specifiche dell'applicazione per le transizioni di stato.

Esistono esempi accessibili al pubblico di tali implementazioni?


3
Lo trovo interessante poiché molte persone affermano che REST è "facile", ma Fielding stesso afferma che sebbene sia un'architettura semplice, non è semplice progettare un'applicazione con essa.
aehlke,

3
a proposito, dovrebbe essere HATEOAS non HATEOS, il successivo non funziona bene su Google.
David Roussel,



Roy Fielding stesso ha mai creato un'applicazione usando HATEOAS?
systemovich

Risposte:


102

Non è un'implementazione nel senso di eseguire il codice, ma mi piace molto l'articolo " Come ottenere una tazza di caffè " su InfoQ. Descrive il processo di ordinazione di un caffè presso Starbucks come protocollo RESTful. Questo va oltre il tipico articolo introduttivo REST "tutto è una risorsa" e si concentra su HATEOAS. Altamente raccomandato.


5
Il libro "Rest in Practice" di Jim Webber, Sayas Parastatidis e Ian Robinson è abbastanza utile
DomreiRoam,

2
L'articolo va bene, ma purtroppo l'API che descrive non aderisce strettamente al principio HATEOAS perché non utilizza tipi di media personalizzati. Come può il cliente sapere come manipolare (ad esempio deserializzare, analizzare, visualizzare) ogni risorsa se tutto è application / xml? Dipenderebbe da alcuni modi non standard di trasmissione di queste informazioni, come la documentazione destinata a essere letta dagli umani.
ygormutti,

21

Che ne dici dell'API Sun Cloud ? Dall'introduzione:

L'API non presuppone una struttura particolare nello spazio URI. Il punto di partenza è un URI, fornito dal fornitore di servizi cloud, che identifica il cloud stesso. La rappresentazione del cloud contiene URI per le altre risorse nel cloud e anche per le operazioni che possono essere eseguite su di essi (ad esempio distribuzione e avvio di macchine virtuali).

Il retroscena potrebbe anche essere utile.


2
È il retroscena che mi ha fatto iniziare il percorso di HATEAOS.
CyberFonic,

3
tutti i collegamenti sono morti
Roeland Van Heddegem il

"Siamo spiacenti che il sito kenai.com sia stato chiuso."
Nick Rolando,

@NickRolando, ho sostituito il link.
Rich Apodaca,

@RichApodaca, il link al backstory è morto.
Vasantha Ganesh K,

7

Netflix ha un'API REST basata su HATEOAS che include collegamenti come parte delle risorse.


1
e ora il codice di stato è 404.
naXa

1
@Il link di Sargent è rotto, per favore aggiorna.
Govi S

Mi dispiace, sembra che Netflix l'abbia rimosso e sia andato con qualcos'altro.
Will Sargent,

2
Le risposte solo link tendono ad essere meno rilevanti quando tali link sono morti.
nyedidikeke,

@nyedidikeke è un link ma una risposta per questo contesto, devi solo correggere il link modificando il post!
Al-Mothafar,

3

La RESTfulness dell'API di Sun Cloud non è effettivamente affrontata nel quarto punto di Roy:

Un'API REST non deve definire nomi o gerarchie di risorse fisse (un ovvio accoppiamento di client e server). I server devono avere la libertà di controllare il proprio spazio dei nomi. Consentire invece ai server di istruire i clienti su come costruire URI appropriati, ad esempio nei moduli HTML e nei modelli URI, definendo tali istruzioni all'interno dei tipi di media e delle relazioni di collegamento. [Il fallimento qui implica che i clienti stanno assumendo una struttura di risorse a causa di informazioni fuori banda, come uno standard specifico del dominio, che è l'equivalente orientato ai dati dell'accoppiamento funzionale di RPC].

Esempio 1 Risolti i nomi delle risorse in un'erede definita:

Dall'API di Sun Cloud: "... la rappresentazione di un VDC includerà rappresentazioni dei cluster che lo popolano, che a loro volta includono rappresentazioni delle macchine virtuali all'interno di ciascun cluster."

Esempio 2 informazioni fuori banda, ad esempio uno standard specifico del dominio:

Devi avere i contenuti della pagina wiki (informazioni fuori banda) per sapere che il "meccanismo di comunicazione delle risorse" per il campo di risorse Cloud "uri" è GET.


2
Hai ragione, è molto fuorviante. Tuttavia, Roy sta parlando dei nomi delle risorse nello spazio uri, non all'interno dei contenuti del tipo di supporto. Sun è libero di modificare l'uri utilizzato per accedere a un cluster in qualsiasi momento. Ovviamente, non può cambiare il termine "cluster" in "gruppo" all'interno della rappresentazione senza creare una nuova versione del tipo di supporto, ma può cambiare l'URI in modo che sia qualsiasi cosa.
Darrel Miller,

4
Sappiamo che l'API Sun utilizza HTTP come interfaccia uniforme, quindi il client non ha bisogno di guardare la pagina wiki per sapere che GET è un verbo valido per la risorsa cloud. Può solo provarlo considerando che sa che GET è un verbo sicuro, oppure può usare OPTIONS per determinare se è disponibile.
Darrel Miller,

3

Mi sono reso conto che questo mi era stato chiesto qualche tempo fa, ma ho preso una pugnalata nel dimostrare un flusso API REST "corretto" per un semplice esempio. Ho provato a seguire le regole di Roy per REST - forse potrebbe essere d'aiuto: Esempio API usando REST

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.