2016-05-26 12 views
6

Quando si utilizzano dati molla per il mio REST API, le risposte restituite attualmente includono il campo _links:Come rimuovere elementi ipermediali dalle rappresentazioni prodotte da Spring Data REST?

{ 
    "_embedded": { 
    "users": [ 
    { 
     "imageUrl": "some_image_url", 
     "name": "some name", 
     "id": "57420b2a0d31bb6cef4ee8e9", 
     "_links": { 
     "self": { 
      "href": "http://localhost:8080/users/57420b2a0d31bb6cef4ee8e9" 
     }, 
     "user": { 
      "href": "http://localhost:8080/users/57420b2a0d31bb6cef4ee8e9{?projection}", 
      "templated": true 
     } 
     } 
    }, 
... 

C'è un modo per produrre in uscita, in modo tale che il campo _links è nascosto? es .:

{ 
    "_embedded": { 
    "users": [ 
    { 
     "imageUrl": "some_image_url", 
     "name": "some name", 
     "id": "57420b2a0d31bb6cef4ee8e9", 
    }, 
... 

trovo che perché sto esponendo il campo id, _links non sono realmente necessari, e per lo più solo ingombrare le mie risposte.

+0

Come si suppone che il cliente sappia dove trovare l'utente senza il collegamento? –

+0

@OliverGierke Ho esposto il campo 'id' nella risposta. –

+0

Cosa fa il client con una stringa semplice che non è un URI? –

risposta

12

Non c'è. Hypermedia è un tratto fondamentale delle API REST e Spring Data REST lo utilizza pesantemente per consentire all'utente di creare client che possano utilizzare i collegamenti presenti nelle risposte per navigare alle risorse correlate.

Ovviamente puoi stupire i tuoi clienti a non utilizzare queste informazioni ma questo porterà ad un accoppiamento molto più stretto (dato che non puoi più cambiare gli URI sul lato server, i tuoi clienti si aspettano di parlare ad un server dedicato mentre con hypermedia puoi semplicemente indirizzarlo a un server diverso, ecc.).

In contrasto con molti altri framework REST autoproclamati, uno degli aspetti chiave del design del framework è il rispetto dei principi fondamentali in REST e l'uso esplicito di questi. O almeno, non creare incentivi per romperli facilmente. Ciò è chiaramente espresso nello reference documentation e nello project website. Scopri di più sulle decisioni chiave di progettazione in this presentation on Spring Data REST e this one on Domain-Driven Design & REST.

Problemi correlati