Codice di stato HTTP per aggiornamento ed eliminazione?

Quale codice di stato devo impostare per UPDATE ( PUT ) e DELETE (ad es. Prodotto aggiornato con successo)?

Per una richiesta PUT : HTTP 200 o HTTP 204 dovrebbe implicare “risorsa aggiornata correttamente”.

Per una richiesta DELETE : HTTP 200 o HTTP 204 dovrebbe implicare “risorsa cancellata con successo”. Si può anche restituire HTTP 202 che implicherebbe che l’istruzione sia stata accettata dal server e che la “risorsa sia stata contrassegnata per la cancellazione”.

9.6 PUT

Se una risorsa esistente viene modificata, devono essere inviati i codici di risposta 200 (OK) o 204 (Nessun contenuto)> per indicare il completamento positivo della richiesta.

9.7 CANCELLA

Una risposta corretta DOVREBBE essere 200 (OK) se la risposta include un’ quadro che descrive lo stato, 202 (Accettato) se l’azione non è stata ancora attuata, o 204 (Nessun contenuto) se l’azione è stata emanata ma la risposta non include un’ quadro.

Fonte: w3.org: definizioni di metodi 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 restituisce alcun contenuto

Fonte: elenco dei codici di stato HTTP: 2xx Successo

Risposta breve: per PUT e DELETE, è necessario inviare 200 (OK) o 204 (Nessun contenuto).

Risposta lunga: ecco un diagramma decisionale completo (clicca per ingrandire).

Diagramma decisionale HTTP 1.1

Fonte: https://github.com/for-GET/http-decision-diagram

Ecco alcuni suggerimenti:

ELIMINA

  • 200 (se si desidera inviare alcuni dati aggiuntivi nella risposta) o 204 (consigliato).

  • 202 L’ operazione cancellata non è stata ancora eseguita.

  • Se non c’è nulla da eliminare, utilizzare 204 o 404 (l’operazione DELETE è idempotente, eliminare un elemento già eliminato è un’operazione riuscita , quindi è ansible restituire 204 , ma è vero che idempotent non implica necessariamente la stessa risposta)

Altri errori:

  • 400 Bad Request (La syntax malformata o una query errata è strana ma ansible).
  • 401 Errore di autenticazione non autorizzata
  • 403 Proibito : errore di authorization o ID applicazione non valido.
  • 405 non consentito . Sicuro.
  • 409 Il conflitto di risorse può essere ansible in sistemi complessi.
  • E 501 , 502 in caso di errori.

METTERE

Se stai aggiornando un elemento di una collezione

  • 200/204 con gli stessi motivi di DELETE sopra.
  • 202 se l’operazione non è stata ancora impegnata.

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 (syntax malformata o una query non valida più comune rispetto a DELETE).

  • 401 non autorizzato
  • 403 Proibito : errore di autenticazione o ID applicazione non valido.
  • 405 non consentito . Sicuro.
  • 409 Conflitto di risorse può essere ansible in sistemi complessi, come in DELETE.
  • 422 Entità non processabile Aiuta a distinguere tra una “Bad request” (es. XML / JSON malformato) e valori di campo non validi
  • E 501 , 502 in caso di errori.

RFC 2616 descrive i codici di stato da utilizzare .

E no, non è sempre 200.

Oltre a 200 e 204, 205 (Resetta contenuto) potrebbe essere una risposta valida.

Il server ha soddisfatto la richiesta e l’agente utente DOVREBBE resettare la vista del documento che ha causato l’invio della richiesta … [es.] Cancellazione del modulo in cui viene fornito l’input.

Poiché la domanda si approfondisce se DELETE “dovrebbe” restituire 200 vs 204 , vale la pena considerare che alcune persone consigliano di restituire un’ quadro con collegamenti, quindi la preferenza è 200 .

“Invece di restituire 204 (nessun contenuto), l’API dovrebbe essere utile e suggerire i luoghi da visitare.In questo esempio penso che un collegamento ovvio da fornire sia” “somewhere.com/container/” (meno ‘risorsa’) “- il contenitore da cui il client ha appena eliminato una risorsa. Forse il cliente desidera eliminare più risorse, quindi sarebbe un collegamento utile. ”

http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/

Se un cliente incontra una risposta 204, può rinunciare, andare al punto di ingresso dell’API o tornare alla risorsa precedente visitata. Nessuna delle due opzioni è particolarmente buona.

Personalmente non direi che 204 è sbagliato (né l’autore, dice “fastidioso”) perché un buon caching presso il cliente ha molti vantaggi. La cosa migliore è essere coerenti in entrambi i modi.

Nel giugno 2014 RFC7231 obsoleto RFC2616. Se si esegue REST su HTTP, RFC7231 descrive esattamente quale comportamento è previsto da GET, PUT, POST e DELETE

Quando una risorsa viene modificata, il codice di risposta deve essere 200 (“OK”) . Se lo stato della risorsa cambia in un modo che modifica l’URI nella risorsa (ad esempio, un account utente viene rinominato), il codice di risposta è 301 (“Spostato in modo permanente”) e l’intestazione Location dovrebbe fornire il nuovo URI.

Quando un object viene cancellato, il codice di risposta deve essere 200 (“OK”).

Segui il link sottostante per maggiori dettagli – codice di stato per il rest