2015-10-07 32 views
5

Ho questa domanda che mi è passata per la testa per un po '. Supponiamo di aver strutturato il nostro progetto con backend e frontend su livelli separati. Così, dal frontend, vogliamo ottenere un cliente, che si accende formato hal+json:come dovrebbe essere gestito Hateoas dal frontend?

GET /customers/1 HTTP/1.1 
Accept: application/hal+json 
{ 
    "name": "Alice", 
    "links": [ { 
     "rel": "self", 
     "href": "http://localhost:8080/customer/1" 
    } { 
     "rel": "transactions", 
     "href": "http://localhost:8080/customer/1/transactions" 
    }] 
} 

Poi, dal frontend voglio ottenere tutte le transazioni dei clienti. La mia domanda è: come devo ottenere l'url? dovrebbe essere dalla risposta? o dovrei costruirlo internamente?

se andiamo con la prima opzione, penso che forse non sarebbe elegante per iterare tutti i collegamenti fino a ottenere quello che vogliamo. Inoltre, potrebbe verificarsi la situazione in cui non abbiamo il link della richiesta che vogliamo fare.

se andiamo con la seconda opzione, non capisco come costruire quell'URL se in realtà non abbiamo gli id. Come potrei creare nuove transazioni con i clienti se gli hateoas sostituiscono gli id ​​con i link e non ho più il riferimento all'oggetto nel corpo?

Ho pensato che forse il servizio dovrebbe supportare sia application/hal+json (orientato agli utenti) che application/json (orientato ai client) ma non vedo che questo è come lo sta facendo in generale.

Cosa ne pensi?

risposta

3

Sicuramente la prima opzione. Vale a dire, dal momento che hateoas è una fase finale di Richardson Maturity Model, i clienti sono tenuti a seguire i link forniti, di non costruire gli URL da soli:

Il punto di controlli ipermediali è che ci dicono cosa possiamo fare prossimo e l'URI della risorsa che dobbiamo manipolare per farlo. Piuttosto che dover sapere dove inviare la nostra richiesta di appuntamento, i controlli ipermediali nella risposta ci dicono come farlo.

Quali vantaggi comporta? Mi vengono in mente almeno due:

  • semplice aggiornamento delle API REST - gli sviluppatori lato server possono cambiare gli URI delle risorse, senza rompere il codice lato client perché i clienti basta seguire i link forniti; Inoltre, gli sviluppatori lato server possono facilmente aggiungere nuovi collegamenti
  • Robustezza: seguendo i collegamenti, il codice lato client non tenterebbe mai di accedere ai collegamenti interrotti, ai collegamenti errati, ecc.

D: Inoltre, ci potrebbe capitare la situazione in cui non abbiamo il link della richiesta che vogliamo fare?

Spetta al progettista API garantire che vengano forniti tutti i collegamenti necessari. Lo sviluppatore front-end non dovrebbe preoccuparsene.

Vedi anche:

+0

Ciò che nel caso ho l'ID utente che voglio aggiungere un'autorità? Quindi dovrei fare una richiesta GET a/utenti per ottenere il link delle autorità dell'utente specificato. Sarebbe ok? sto facendo 2 richieste invece di una. Grazie per la risposta! – jscherman

+2

non dovresti avere un ID da un sistema esterno. dovresti avere un URL. E sì, sono 2 richieste ... a meno che il server non sia abbastanza intelligente da capire le tue intenzioni. quindi ad esempio potrebbe incorporare la relazione di transazione per te. Un modo in cui potresti dargli quell'intento è identificando il client che consuma con un'intestazione. Ma non preoccuparti troppo delle 2 richieste, è un prezzo molto basso da pagare. ORA, se sei interno ... perché stai usando un API HTTP comunque? basta andare al DB/sistema o registrare e ottenere i dati necessari. –

+0

Penso di aver capito il tuo punto. Grazie! – jscherman

1

HATEOAS (Hypermedia come il motore dello stato dell'applicazione) è un vincolo dell'architettura dell'applicazione REST. Si può avere uno sguardo sulla documentazione primavera hateoas per esempio:

https://spring.io/understanding/HATEOAS

Un altro collegamento su di esso con la primavera e l'AngularJS è disponibile qui:

AngularJS and Spring HATEOAS tutorial

Questo sembra essere abbastanza buono e gestisce il tuo caso d'uso.

Cordiali saluti, André