Quale codice di stato devo impostare per UPDATE( PUT) e DELETE(es. Prodotto aggiornato con successo)?
Codice di stato HTTP per l'aggiornamento e l'eliminazione?
Risposte:
Per una richiesta PUT : HTTP 200 o HTTP 204 dovrebbero implicare "risorsa aggiornata correttamente".
Per una richiesta DELETE : HTTP 200 o HTTP 204 dovrebbero implicare "risorsa eliminata correttamente". HTTP 202 può anche essere restituito, il che implicherebbe che l'istruzione è stata accettata dal server e che la "risorsa è stata contrassegnata per l'eliminazione".
Se una risorsa esistente viene modificata, i codici di risposta 200 (OK) o 204 (Nessun contenuto)> DOVREBBERO essere inviati per indicare il completamento con successo della richiesta.
Una risposta corretta DOVREBBE essere 200 (OK) se la risposta include un'entità che descrive lo stato, 202 (Accettato) se l'azione non è stata ancora attuata o 204 (Nessun contenuto) se l'azione è stata attuata ma la risposta non include un'entità.
Fonte: W3.org: definizioni del metodo HTTP / 1.1
HTTP 200 OK: risposta standard per richieste HTTP riuscite. La risposta effettiva dipenderà dal metodo di richiesta utilizzato.
HTTP 204 Nessun contenuto: il server ha elaborato correttamente la richiesta, ma non sta restituendo alcun contenuto
40
Post molto utile! Tuttavia mi chiedo quale dovrebbe essere il codice di stato HTTP se la richiesta inviata dal client è valida (DELETE mySite / entity / 123 ) e l'entità da eliminare non esiste.
—
Martin,
@Martin: In tal caso, il servizio dovrebbe restituire un HTTP 404. A rigor di termini, una richiesta DELETE o GET per una risorsa che non esiste non è una richiesta "valida" - vale a dire. il client non deve tentare nuovamente tale richiesta perché non riuscirà mai ... Il protocollo HTTP definisce 2 categorie di problemi: quelli con un codice di stato 4xx, in cui il client deve modificare la richiesta prima di riprovare e quelli con uno stato 5xx codice, che indica che il servizio ha avuto problemi e che il client dovrebbe / potrebbe ritentare la stessa richiesta esatta senza modificarlo.
—
Daniel Vassallo,
@JeffMartin Potrebbe essere così dal punto di vista dell'utente, ma per quanto riguarda il server, se la risorsa non esiste, il server dovrebbe restituire 404.
—
Randolpho,
@Randolpho, Idempotence significa ottenere lo stesso risultato se invochi un'operazione una o più volte. Il client richiede di assicurarsi che la risorsa sia stata eliminata. Qual è il vantaggio di restituire 404? Perché ha bisogno di sapere in entrambi i modi? Ora la logica del client deve gestire due codici di risposta separati anziché uno.
—
Gili,
@Gili: forse il wiki spiegherà meglio: i metodi PUT e DELETE sono definiti come idempotenti ... nota che idempotenza si riferisce allo stato del sistema dopo che la richiesta è stata completata, quindi mentre l'azione intraprende il server (es. L'eliminazione di un record ) o il codice di risposta che restituisce potrebbe essere diverso nelle richieste successive, lo stato del sistema sarà lo stesso ogni volta.
—
Randolpho,
Risposta breve: sia per PUT che per DELETE, è necessario inviare 200 (OK) o 204 (Nessun contenuto).
Risposta lunga: ecco un diagramma decisionale completo (clicca per ingrandire).
Il diagramma è fantastico. Esiste una versione a risoluzione più elevata per la stampa?
—
KiKi,
Nel contesto di POST di una risorsa esistente, un'altra discussione SO ( stackoverflow.com/questions/3825990/… ) suggerisce di inviare 409 Conflict o 302 Found invece di aggiungere il contenuto.
—
koppor,
Sono curioso di sapere se la risposta 204 e 200 dopo il verificarsi di un'eliminazione debba essere invertita e se sono corretti così com'è, perché? Cancellato? -> La risposta include un'entità? -> sì -> 204 Nessun contenuto; no -> 200 OK
—
matth
La versione aggiornata dell'immagine è qui: raw.github.com/for-GET/http-decision-diagram/master/httpdd.png
—
zaius
Manca PATCH.
—
Doremi,
Ecco alcuni suggerimenti:
ELIMINA
200 (se si desidera inviare alcuni dati aggiuntivi nella risposta) o 204 (consigliato).
202 Operazione eliminata non è stata ancora impegnata.
Se non c'è nulla da eliminare, utilizzare 204 o 404 (l'operazione ELIMINA è idempotente, l'eliminazione di un elemento già eliminato ha esito positivo , pertanto è possibile restituire 204 , ma è vero che idempotente non implica necessariamente la stessa risposta)
Altri errori:
- 400 Richiesta errata (sintassi errata o query errata è strana ma possibile).
- 401 Errore di autenticazione non autorizzata
- 403 Proibito : errore di autorizzazione o ID applicazione non valido.
- 405 non consentito . Sicuro.
- 409 Il conflitto di risorse può essere possibile in sistemi complessi.
- E 501 , 502 in caso di errori.
METTERE
Se stai aggiornando un elemento di una raccolta
- 200/204 con gli stessi motivi di ELIMINA sopra.
- 202 se l'operazione non è stata ancora eseguita.
L'elemento di riferimento non esiste:
- PUT può essere 201 (se hai creato l'elemento perché quello è il tuo comportamento)
404 Se non si desidera creare elementi tramite PUT.
400 Richiesta non valida (sintassi non valida o query non valida più comune che nel caso di ELIMINA).
- 401 Non autorizzato
- 403 Proibito : autenticazione non riuscita o ID applicazione non valido.
- 405 non consentito . Sicuro.
- 409 Il conflitto di risorse può essere possibile in sistemi complessi, come in ELIMINA.
- 422 Entità non elaborabile Aiuta a distinguere tra "Richiesta non valida" (ad es. XML / JSON non valido) e valori di campo non validi
- E 501 , 502 in caso di errori.
Questa risposta è composta quasi interamente da due grandi virgolette, ma non c'è attribuzione. Da dove stai citando?
—
Quentin,
204 è uno stato appropriato da restituire per una richiesta PUT, se lo stato non viene modificato in modo efficace? Ad esempio, si chiede di disattivare un utente ma l'utente è già inattivo.
—
Ε Г И І И О
La richiesta PUT è idempotente, quindi è possibile restituire un 204, poiché l'oggetto è cambiato nel sistema. PUT non è PATCH, quindi non sei sicuro di quale campo desideri modificare. Puoi restituire un 501 - 502, se il tuo progetto deve sapere se l'oggetto era esattamente uguale all'oggetto nella richiesta ma ... Non mi piace molto .. Preferisco 204 o, se vuoi disattivare un utente, senza cambiare più campi, forse puoi usare PATCH.
—
Alfonso Tienda,
Aggiungerei Entità non elaborabile HTTP 422. Aiuta a distinguere tra "Richiesta errata" (ad es. XML / JSON non valido) e valori di campo non validi.
—
vdboor,
RFC 2616 descrive quali codici di stato utilizzare .
E no, non sono sempre 200.
Oltre a 200 e 204, 205 (Reimposta contenuto) potrebbe essere una risposta valida.
Il server ha soddisfatto la richiesta e l'agente utente DOVREBBE reimpostare la vista del documento che ha causato l'invio della richiesta ... [es.] Cancellazione del modulo in cui viene fornito l'input.
Poiché la domanda approfondisce se DELETE "dovrebbe" restituire 200 vs 204 , vale la pena considerare che alcune persone raccomandano di restituire un'entità con collegamenti, quindi la preferenza è per 200 .
"Invece di restituire 204 (nessun contenuto), l'API dovrebbe essere utile e suggerire luoghi dove andare. In questo esempio penso che un link ovvio da fornire sia" "somewhere.com/container/ '(meno' risorsa ') " - il contenitore da cui il client ha appena eliminato una risorsa. Forse il client desidera eliminare più risorse, quindi sarebbe un collegamento utile. "
http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/
Se un client rileva una risposta 204, può rinunciare, andare al punto di ingresso dell'API o tornare alla risorsa precedente visitata. Nessuna opzione è particolarmente buona.
Personalmente non direi che 204 sia sbagliato (né l'autore; dice "fastidioso") perché una buona memorizzazione nella cache sul lato client ha molti vantaggi. La cosa migliore è essere coerenti in entrambi i modi.
Ecco un codice di stato, che dovresti conoscere per il tuo tipo di conoscenza.
1XX Risposte alle informazioni
- 100 Continua
- 101 Protocolli di commutazione
- 102 Elaborazione
- 103 suggerimenti iniziali
2XX successo
- 200 OK
- 201 creato
- 202 Accettato
- 203 Informazioni non autorevoli
- 204 Nessun contenuto
- 205 Ripristina contenuto
- 206 Contenuto parziale
- 207 Stato multiplo
- 208 già segnalato
- 226 IM usato
Reindirizzamento 3XX
- 300 scelte multiple
- 301 spostato in modo permanente
- 302 trovati
- 303 Vedi Altro
- 304 non modificato
- 305 Usa proxy
- 306 Switch proxy
- 307 Reindirizzamento temporaneo
- 308 reindirizzamento permanente
4XX Errori client
- 400 Richiesta non valida
- 401 Non autorizzato
- 402 pagamento richiesto
- 403 proibito
- 404 non trovato
- 405 Metodo non consentito
- 406 Non accettabile
- 407 Autenticazione proxy richiesta
- 408 Timeout richiesta
- 409 Conflitto
- 410 Andato
- 411 Lunghezza richiesta
- 412 Condizione preliminare non riuscita
- 413 Carico utile troppo grande
- 414 URI troppo lungo
- 415 Tipo di supporto non supportato
- Gamma 416 non soddisfacente
- 417 Aspettativa fallita
- 418 Sono una teiera
- 420 Metodo Failure
- 421 Richiesta errata
- 422 Entità non elaborabile
- 423 bloccato
- 424 Dipendenza non riuscita
- 426 Aggiornamento richiesto
- 428 Requisito necessario
- 429 Troppe richieste
- 431 Campi di richiesta richiesta troppo grandi
- 451 Non disponibile per motivi legali
Errori del server 5XX
- 500 Errore interno del server
- 501 non implementato
- 502 Gateway non valido
- 503 Servizio non disponibile
- Timeout gateway 504
- 505 Versione http non supportata
- 506 Vari Anche negoziare
- 507 Memoria insufficiente
- 508 Rilevato loop
- 510 non esteso
- 511 Autenticazione di rete obbligatoria
Quando una risorsa viene modificata, il codice di risposta dovrebbe essere 200 ("OK") . Se lo stato della risorsa cambia in modo da modificare l'URI nella risorsa (ad esempio, un account utente viene rinominato), il codice di risposta è 301 ("Spostato in modo permanente") e l'intestazione Ubicazione deve fornire il nuovo URI.
Quando un oggetto viene eliminato, il codice di risposta dovrebbe essere 200 ("OK").
Segui il link sotto per maggiori dettagli - codice di stato per il resto