Esistono strategie per scoprire i servizi REST utilizzando HATEOAS?

10

Quando si crea un servizio REST con il vincolo HATEOAS , è molto facile pubblicizzare l'esistenza delle risorse attraverso il collegamento. Accedete GETalla radice del mio sito e io rispondo con il documento radice che elenca tutte le risorse di primo livello:

{
    users: { href: "/users" }
    questions { href: "/questions" }
}

I clienti che comprendono come leggere questi hrefvalori possono eseguire GETrichieste su tali valori e scoprire tutte le risorse correnti disponibili nell'applicazione.

Funziona bene per gli scenari di ricerca di base, ma non indica se una risorsa è interrogabile. Ad esempio, può essere ragionevole eseguire:

GET /users?surname=Smith

Esistono formati in grado di esprimere questa capacità di query con informazioni sufficienti a consentire a un client di formare una query coerente senza la necessaria conoscenza preliminare della risorsa?

Inoltre, esiste un modo per esprimere che un client è autorizzato a eseguire POSTuna determinata posizione con una posizione prevista. Ad esempio, ci si potrebbe aspettare che un client esegua quanto segue per creare una nuova risorsa di domanda:

POST /questions

{
    title: "Are there strategies for discovering REST services using HATEOAS?",
    body: "When building a REST service with the HATEOAS constraint, it's very..."
}

Quando si utilizza HTML come formato per il consumo umano, possiamo esprimere molto di ciò attraverso l'uso di moduli e istruzioni scritte per consentire a un essere umano di scoprire le operazioni che gli è consentito eseguire su un servizio.

Esistono formati capaci di cose simili per i clienti?

design rest hateoas

— Paul Turner
fonte

2

Il problema con la scoperta di un servizio REST è stato discusso e risolto qui: stackoverflow.com/questions/9101494/… La soluzione più semplice è quella di utilizzare un modello XHTML con un modulo che spieghi non solo il metodo che puoi usare ma anche il struttura dell'oggetto da inviare tramite gli elementi del modulo (input, seleziona ecc.). I clienti devono solo avere un parser XML per trovare ciò di cui hanno bisogno. Un altro modo è con i modelli di URL ma aiutano solo con risorse che accettano stringhe di query.

— Spoike,

Per quanto riguarda i tipi di contenuto; ciò è risolto con la negoziazione del contenuto che viene eseguita nelle intestazioni HTTP. Se il server non può servire un tipo di contenuto richiesto, dovrebbe restituire un errore HTTP (come 300 o 406) che indica quali tipi di contenuto può restituire.

— Spoike,

1

Come faresti a sapere che tipo di input sono accettabili? Vale a dire, se il tuo cliente non ha alcuna conoscenza precedente, come definiresti la semantica del "cognome"? Stai iniziando a entrare nel territorio di aver bisogno di qualcosa come OWL .

Penso che sia più pratico aspettarsi che i tuoi clienti comprendano la semantica di noti tipi mime; ad esempio, "testo / vcard" per le persone.

— Stephen J. Anderson
fonte

Penso che l'uso del tipo di contenuto sia la strada da percorrere; Potrei facilmente cambiare la mia applicazione per usarla application/atomapp+xmle renderla disponibile per tutti i client che già comprendono questo formato. Probabilmente ci sono abbastanza tipi di contenuto ben noti là fuori per rendere questa una soluzione pratica.

— Paul Turner,

Penso che il commento di @Spoike sia un elegante approccio REST-ian all'altra metà del problema; anche se il client sa che (ad esempio) un utente è rappresentato come una vCard, deve comunque sapere quale sottoinsieme delle proprietà dell'utente è disponibile per la ricerca.

— Stephen J. Anderson,

4

Puoi pubblicare i dettagli sui tuoi servizi tramite un "WADL"

http://en.wikipedia.org/wiki/Web_Application_Description_Language

È facoltativo e non tutti i backend REST technos lo supportano. Jersey, l'implementazione java "ufficiale" di jax-rs, ad esempio, la supporta: può essere generata automaticamente per te.

È abbastanza raro però vederlo usato.

Non conosco quelli grandi che lo usano. In generale hai una pagina web che descrive l'API.

— unludo
fonte

1

CXF è un'altra grande implementazione Java JAX-RS che supporta WADL e ora stai iniziando a vedere anche alcuni interessanti consumatori WADL di terze parti.

— Donal Fellows,

0

La primavera ha un po 'di supporto per questo, così come a disagio.

— jiggy
fonte