Un'operazione "PUT" RESTful dovrebbe restituire qualcosa
Mi chiedevo quali sono le opinioni delle persone riguardo a un'operazione PUT RESTful che restituisce nulla (null) nel corpo della risposta.
La specifica HTTP ( RFC 2616 ) ha un numero di raccomandazioni applicabili. Ecco la mia interpretazione:
- Codice di stato HTTP
200 OKper un PUT corretto di un aggiornamento a una risorsa esistente. Non è necessario alcun corpo di risposta. (Per Sezione 9.6 ,204 No Contentè ancora più appropriato.) - Codice di stato HTTP
201 Createdper un PUT di successo di una nuova risorsa, con l'URI più specifico per la nuova risorsa restituita nel campo dell'intestazione Location e qualsiasi altro URI e metadati pertinenti della risorsa riportati nel corpo della risposta. ( RFC 2616 Sezione 10.2.2 ) - Codice di stato HTTP
409 Conflictper un PUT non riuscito a causa di un 3rd-party modification, con un elenco di differenze tra l'aggiornamento tentato e la risorsa corrente nel corpo della risposta. ( RFC 2616 Sezione 10.4.10 ) - Codice di stato HTTP
400 Bad Requestper un PUT non riuscito, con testo in lingua naturale (come l'inglese) nel corpo della risposta che spiega perché il PUT non è riuscito. ( RFC 2616 Sezione 10.4 )
A differenza della maggior parte delle risposte qui, penso che PUT debba restituire la risorsa aggiornata (oltre ovviamente al codice HTTP).
Il motivo per cui si desidera restituire la risorsa come risposta per l'operazione PUT è perché quando si invia una rappresentazione di risorse al server, il server può anche applicare alcune elaborazioni a questa risorsa, quindi il client vorrebbe sapere come fa questa risorsa sembra che la richiesta sia stata completata con successo. (altrimenti dovrà emettere un'altra richiesta GET).
Penso che sia possibile per il server restituire il contenuto in risposta a un PUT. Se si utilizza un formato di busta di risposta che consente di trasferire i dati trasferiti (come il formato consumato dai dati ember), è possibile includere anche altri oggetti che potrebbero essere stati modificati tramite trigger di database, ecc. (I dati trasferiti in parallelo riducono esplicitamente # di richieste e questo sembra un buon posto per ottimizzare.)
Se accetto solo il PUT e non ho nulla da riferire, utilizzo il codice di stato 204 senza corpo. Se ho qualcosa da segnalare, utilizzo il codice di stato 200 e includo un corpo.
La specifica HTTP/1.1 (sezione 9.6) discute i codici di risposta/errore appropriati. Tuttavia non affronta il contenuto della risposta.
Cosa ti aspetti? Un semplice codice di risposta HTTP (200 ecc.) Mi sembra semplice e inequivocabile.
Ho usato RESTful API nei miei servizi, ed ecco la mia opinione: per prima cosa dobbiamo arrivare a una visione comune: PUT è usato per aggiornare una risorsa che non è stata creata o ottenuta.
Ho definito le risorse con: Stateless resource e Stateful resource:
Risorse senza stato Per queste risorse, basta restituire il codice Http con il corpo vuoto, è sufficiente.
Risorse stateful Ad esempio: la versione della risorsa. Per questo tipo di risorse, è necessario fornire la versione quando si desidera modificarla, quindi restituire la risorsa completa o restituire la versione al client, in modo che il client non debba inviare una richiesta di ottenere dopo l'azione di aggiornamento.
Ma , per un servizio o sistema, tenerlo simple, clearly, easy to use and maintain è la cosa più importante .
Codice di risposta HTTP di 201 per "Creato" insieme a un'intestazione "Posizione" per indicare dove il client può trovare la risorsa appena creata.
Se il backend dell'APIREST è un database relazionale SQL, allora
- dovresti avere RowVersion in ogni record che può essere aggiornato (per evitare il problema di aggiornamento perso )
- dovresti restituire sempre una nuova copia del record dopo PUT (per ottenere la nuova RowVersion ).
Se non ti interessa aggiornamenti persi, o se vuoi forzare i tuoi clienti a fare un GET immediatamente dopo un PUT, allora non restituire nulla da PUT.