Progettazione API REST: collegamento risorse

Supposto che disponga di due risorse di livello superiore Foo e Bar. Ora è necessario collegare lo Foo ad alcuni degli Bar. In una classe Java che questo potrebbe essere simile a questa:Progettazione API REST: collegamento risorse

public class Foo { 

    Set<Bar> bars; 
} 

public class Bar { … }

mi piacerebbe modellare la rappresentazione XML Foo a qualcosa di simile:

GET /foos/1 

<foo> 
    … 
    <atom:link rel="self" href="/foos/1" /> 
    <atom:link rel="bars" href="/foos/1/bars" /> 
</foo>

Così ho esporre praticamente tutto Barassegnato a Foo come risorsa nidificata. Ciò significa che la risorsa Bar ha un ciclo di vita individuale (aggregazione anziché composizione). La risorsa nidificato potrebbe quindi esporre tutte legate Bar qualcosa di simile:

GET /foos/1/bars 

<bars> 
    <atom:link rel="bar" href="/foos/1/bars/1" /> 
    <atom:link rel="bar" href="/foos/1/bars/2" /> 
</bars>

Alteratively ho potuto inline la collezione nel <foo> elemento in anticipo. Tuttavia, sono ancora bloccato con alcune domande: mentre ciò mi consente di rimuovere con precisione un da attivando una richiesta DELETE ad es. /foos/1/bars/1 ma come si assegnerebbe uno Bar a un Foo quindi? Supponendo che il cliente avrebbe accedere /bars ottenere:

GET /bars 

<bars> 
    <bar> 
    … 
    <atom:link rel="self" href="/bars/4711" /> 
    </bar> 
</bars>

e decidere che vuole assegnare /bars/1-/foo/1/bars. Stavo pensando a una richiesta POST su /foo/1/bars ma non ero sicuro su cosa inviare effettivamente. Un elemento link che punta alla risorsa Bar come la seguente?

POST /foos/1/bars 

<atom:link href="/bars/4711" />

Questo sembra abbastanza bene come i clienti avrebbero ancora bisogno di creare URL e ci continua a soddisfare i vincoli di riposo. Tuttavia sembra un po 'strano ai collegamenti POST al server. C'è una soluzione migliore per questo scenario?

fonte

2012-01-11 Oliver Gierke

Non avrei alcuna esitazione nel POST di un collegamento per stabilire una relazione tra due risorse. Alcune persone credono che tu debba recuperare la risorsa e poi POST che sia auto-descrittiva, ma non sono convinto che sia necessario. –

Questo è quello che sento anche perché tu sei un) creare inutili chiacchiere eb) non è necessario che l'intera versione sul lato server crei effettivamente il collegamento. –

Penso a questo in termini di risorse capite dal server piuttosto che le rappresentazioni XML che fluiscono in risposta a (diciamo) una richiesta GET. Dispongo di servizi RESTful che restituiscono JSON o XML o potenzialmente altre rappresentazioni.

Quindi sono d'accordo con il vostro invio o mettendo a

/foos/{fooId}/bars

per specificare l'elenco completo di bar o l'aggiunta di alcuni bar.

Il formato del payload pubblicato può essere qualunque sia la forma serializzata naturale per il tipo di supporto che stai utilizzando. Nel mio caso è spesso una stringa JSON e quindi nella mia implementazione del servizio si deserializzerebbe e vedremo una serie di stringhe di riferimento URL di riferimento.

Se il

<atom:link href="/bars/4711" />

deserialise anche ben quindi non vedo un problema se il modulo serializzato è un po ', ehm, ornamentale.

Riepilogo: fai ciò che è naturale per il tuo (de) serializzatore.

fonte

2012-01-11 11:20:25 djna

In realtà non penso che la rappresentazione attuale abbia importanza qui. La stessa domanda si presenterebbe se stavo usando JSON. Ho scelto XML come esempio qui perché esiste un elemento 'link' standard e dovrei inventarmi qualcosa in JSON. Grazie comunque per la tua risposta! –

bene la rappresentazione nel tuo caso ha le parole atomo: link, e ho pensato che fosse la causa della tua preoccupazione. Un ID univoco come "/ bars/4711" mi sembra abbastanza indiscriminato - devi avere qualche id, giusto? – djna

Esatto, la ragione per cui questo mi sembra un po 'strano è che ho inviato solo i collegamenti dal server al client per consentire al client di navigare tra le risorse. Non ho mai avuto la necessità di postare un link e di essere stato intrappolato dal sentimento che il cliente avrebbe dovuto creare l'URL e quindi infrangere i principi REST. Ma in realtà lo scopre in anticipo, quindi dovrei andare bene. –

Progettazione API REST: collegamento risorse

risposta

Problemi correlati