2014-09-17 12 views
8

Ho un endpoint di richiesta POST, in cui l'utente pubblica ripetutamente i dati. Prima di inserire i dati nel database, in base alla richiesta dell'utente, controllo se il record esiste già. - Se il record esiste già, torno 200 OK con il corpo di risposta contenente il table_id e lo stato - Se record non esiste, creo nuovo record e ritorno 200 OK con il corpo di risposta contenente table_id e lo statoRichiesta POST RESTful, Se il record esiste già sui dati POST, si restituisce 200 OK o 304 Non modificato?

In sostanza sia nella casi, l'utente ottiene lo stato 200. Come utente potrebbe confondere poiché non si è in grado di distinguere se si tratta di un nuovo record o di un record esistente.

Ho pensato di restituire 304 con il corpo della risposta e informare il consumatore dicendo che questa richiesta è "Non modificata", in questo modo i consumatori prenderebbero una decisione.

È una buona pratica o esiste un approccio alternativo nei principal RESTful.

+0

Ho trovato questo argomento interessante qui [http-response-code-for-post-when-resource-already-exists] (https://stackoverflow.com/questions/3825990/http-response-code-for- post-quando-resource-già-esistente? RQ = 1). Quale si desidera utilizzare 302 - FOUND, 303 - Vedi Altro, 304 - Non modificato. 302 ha più senso per me :-) –

+0

La RFC [link] (https://tools.ietf.org/html/rfc7231#section-4.3.3) nota che 303 (vedi Altro) dovrebbe essere usato. – Nullius

+0

Possibile duplicato di [codice di risposta HTTP per POST quando la risorsa esiste già] (https://stackoverflow.com/questions/3825990/http-response-code-for-post-when-resource-already-exists) –

risposta

9

304 è destinato ad essere utilizzato solo per un condizionaleGET risposta , per indicare che il contenuto richiesto non è cambiato dall'ultima volta che il cliente ha chiesto per questo. Non è appropriato per una risposta POST.

Per una risposta POST, utilizzare 201 se viene creato un nuovo record, altrimenti utilizzare 200 o forse 409 invece.

vedere il seguente per alcuni suggerimenti utili nella progettazione di API REST:

Using HTTP 304 in response to POST

HTTP response code for POST when resource already exists

Creating an efficient REST API with HTTP

REST lesson learned: Avoid 204 responses

1

304 Not Modified è da utilizzare quando intestazioni HTTP caching sono in gioco, quindi questa daina non si applica al tuo caso.

Vorrei utilizzare 422 Unprocessable Entity che è per errori di convalida, quando la richiesta è ben formata ma ci sono errori semantici.

E se il record non esisteva in precedenza, è necessario rispondere con 201 Created (anziché 200 OK) che è la risposta standard a una creazione di risorsa riuscita (in seguito a una richiesta di creazione POST).

Problemi correlati