Progettare il ponte tra il livello REST e il livello di servizio

Question

Progettare il ponte tra il livello REST e il livello di servizio

#1 da (1 voti)

1

Sto lavorando a un progetto e vorrei esporre alcuni servizi REST. Le tecnologie utilizzate sono RestEasy, EJB e JPA / Hibernate. Ho strutturato la mia app in modo che vi sia una chiara delimitazione tra il livello di servizio e il livello del modello. Un servizio tipico che recupera i dati dal database ha una firma come questa: getWhateverList(idForWhichTheListWillBeRetrieved, start) - quindi piuttosto semplice.

Quello che sto facendo fatica a racchiudere la mia mente è come riunire la rigidità del livello di servizio con la flessibilità del livello REST. Supponiamo ad esempio che mi piacerebbe un tipico metodo GET che produca operazioni di supporto dell'array JSON come:

filtering - usa un parametro query per ottenere, ad esempio, elementi che hanno una proprietà di tipo data maggiore / minore del parametro che fornisco
ordinamento - L'API REST dovrebbe supportare asc o desc
limitando i campi restituiti dall'operazione GET

Come si può fare per progettare questo?

design architecture rest

posta Radu 22.11.2013 - 09:42

fonte

1 risposta

Leggi altre domande sui tag design architecture rest

Che succede con l'idioma Class :: get (id) in PHP Quando aggiungi 7, 3 e 1 in un albero rosso-nero, devo eseguire una rotazione corretta?

score 1 · Answer 1

filtering - use a query param to get, for example items that have a property of type date greater/lower than the param that I provide

Per questo è necessario un linguaggio di query. Puoi utilizzare qualsiasi linguaggio di query esistente finché lo descrivi con i metadati nei tuoi link. Quindi i tuoi client e server possono avere un contratto comune che è descritto da quei metadati. Ad esempio GET /users?q="statement using a standard query language" .

Puoi descrivere semplici query utilizzando modelli URI . Ad esempio GET /users?firstName={firstName}

sorting - rest api should support asc or desc

Puoi utilizzare gli stessi link descritti sopra con parametri di query aggiuntivi. Ad esempio GET /users?sortBy="name"&direction="asc" .

limiting the fields that are returned from the GET operation

Puoi utilizzare gli stessi link descritti sopra con parametri di query aggiuntivi. Ad esempio GET /users?fields="firstName,secondName,age" .

nota: in base all'interfaccia uniforme / vincolo HATEOAS devi inviare collegamenti ai tuoi clienti. In base al vincolo di interfaccia uniforme / messaggi autodescrittivi, questi collegamenti devono contenere metadati (ad esempio la relazione di collegamento) su ciò che sono. Quindi i clienti possono controllare i metadati e scegliere il collegamento corretto per raggiungere il loro obiettivo.