Va bene da REST per restituire il contenuto dopo il POST?

Question

Sto utilizzando RESTlet e ho creato una risorsa. Gestisco POST sovrascrivendo il metodo acceptRepresentation.

Il client deve inviarmi alcuni dati, quindi lo memorizzo in DB, impostare la risposta su 201 (SUCCESS_CREATED) e ho bisogno di restituire alcuni dati al client, ma restituire il tipo di acceptRepresentation è nullo.

Nel mio caso ho bisogno di tornare un identificatore in modo che il cliente può accedere a tale risorsa.

Per esempio, se ho avuto una risorsa con URL/risorsa e client invia richiesta POST aggiungo nuova riga nel DB e il suo indirizzo deve essere/risorse/{id}. Devo inviare {id}.

Sto facendo qualcosa di sbagliato? I principi REST consentono di restituire qualcosa dopo il POST? Se sì, come posso farlo, e se no, qual è il modo di gestire questa situazione?

Answer 1

REST dice solo che si dovrebbe conformarsi al un'interfaccia uniforme. In altre parole, dice che dovresti fare ciò che il POST dovrebbe fare come per lo HTTP spec. Ecco la citazione di quella specifica che è rilevante,

Se una risorsa è stata creata sul server provenienza, la risposta dovrebbe essere 201 (Creato) e contengono un soggetto che descrive lo stato del richiesta e fa riferimento alla nuova risorsa e all'intestazione di posizione (vedere la sezione 14.30).

Come puoi vedere da questo, hai due posti in cui puoi indicare al cliente dove risiede la risorsa appena creata. L'intestazione Location dovrebbe avere un URL che punta alla nuova risorsa e puoi anche restituire un'entità con i dettagli.

Non sono sicuro di quale sia la differenza tra l'overriding di acceptRepresentation() e l'overriding post() ma l'esempio this mostra come restituire una risposta da un POST.

Answer 2

uscita in tutto ciò che è richiesto in formato. Che potrebbe essere:

<success> 
    <id>5483</id> 
</success> 

Oppure:

{ "type": "success", "id": 5483 } 

Dipende da quello che fai di solito. Se non si aspettano i dati, dovrebbero semplicemente ignorarlo, ma qualsiasi client che voglia gestirlo correttamente dovrebbe essere in grado di farlo.

Answer 3

Due diverse domande:

supporta il modello di applicazione REST la restituzione dei dati in un post?

Non penso che REST lo neghi esplicitamente, ma il trattamento preferito è spiegato nella risposta di Darrel.

Vuol quadro Restlet consentire la restituzione dei dati in un post?

Sì, anche se restituisce void, in una classe che estende Risorsa, si ha accesso completo all'oggetto oggetto Risposta tramite il metodo getResponse(). Quindi puoi chiamare getResponse(). SetEntity() con qualsiasi dato tu voglia.

Answer 4

Se si risponde 201 Creato con un corpo di entità, piuttosto che un reindirizzamento di posizione, allora è una buona idea includere un'intestazione Content-Location che punta alla risorsa che viene rappresentata nella risposta.

Ciò eviterà la potenziale confusione - in cui un cliente potrebbe (giustamente) presumere che l'entità di risposta rappresenti effettivamente un nuovo stato del "creatore" e non la risorsa creata.

> POST /collection 
> ..new item.. 

< 201 Created 
< Location: /collection/1354 
< Content-Location: /collection/1354 
< <div class="item">This is the new item that was created</div> 

Answer 5

Non rinuncerei a inviare nulla nel corpo della risposta. Basta impostare la posizione: all'URL (completo) della risorsa appena creata.

tua descrizione suggerisce che questo è esattamente la semantica voi:

1. POST una cosa per crearlo
2. Rispondere con abbastanza per sapere due cose:
   1. che la creazione è accaduto (la 201
   2. Dove trovare la nuova cosa (l'intestazione di posizione)

Tutto il resto è superfluo. risposta