Qual è un codice di stato HTTP appropriato da restituire da un servizio API REST per un errore di convalida?

Attualmente restituisco 401 Non autorizzato ogni volta che riscontro un errore di convalida nella mia applicazione API REST basata su Django / Piston . Dopo aver dato un'occhiata al registro dei codici di stato HTTP, non sono convinto che si tratti di un codice appropriato per un errore di convalida, cosa raccomandate?

• 400 Richiesta non valida
• 401 Non autorizzato
• 403 proibito
• 405 Metodo non consentito
• 406 Non accettabile
• 412 Condizione preliminare non riuscita
• 417 Aspettativa fallita
• 422 Entità non elaborabile
• 424 Dipendenza non riuscita

Aggiornamento : "Errore di convalida" di cui sopra indica un errore di convalida dei dati a livello di applicazione, ad esempio datetime specificato in modo errato, indirizzo di posta elettronica fasullo ecc.

Se "errore di convalida" indica che nella richiesta è presente un errore client, utilizzare HTTP 400 (Richiesta non valida). Ad esempio, se l'URI dovrebbe avere una data ISO-8601 e scopri che è nel formato sbagliato o si riferisce al 31 febbraio, allora restituiresti un HTTP 400. Idem se ti aspetti un XML ben formato in un corpo di entità e non riesce ad analizzare.

(1/2016): Negli ultimi cinque anni il più specifico HTTP 422 (Unprocessable Entity) di WebDAV è diventato un'alternativa molto ragionevole a HTTP 400. Vedi ad esempio il suo utilizzo nell'API JSON . Ma nota che HTTP 422 non è diventato HTTP 1.1, RFC-7231 .

I servizi Web RESTful di Richardson e Ruby contengono un'appendice molto utile su quando utilizzare i vari codici di risposta HTTP. Dicono:

400 ("Richiesta non valida")
Importanza: alta.
Questo è lo stato di errore generico lato client, utilizzato quando nessun altro codice di errore 4xx è appropriato. Viene comunemente utilizzato quando il client invia una rappresentazione insieme a una richiesta PUT o POST e la rappresentazione è nel formato corretto, ma non ha alcun senso. (p. 381)

e:

401 ("Non autorizzato")
Importanza: alta.
Il client ha tentato di operare su una risorsa protetta senza fornire le credenziali di autenticazione appropriate. Potrebbe aver fornito le credenziali sbagliate o nessuna. Le credenziali possono essere un nome utente e una password, una chiave API o un token di autenticazione, qualunque sia il servizio in questione. È comune per un client fare una richiesta per un URI e accettare un 401 solo per sapere quale tipo di credenziali inviare e in quale formato. [...]

Da RFC 4918 (e anche documentato su http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml ):

Il codice di stato 422 (entità non elaborabile) indica che il server comprende il tipo di contenuto dell'entità richiesta (quindi un codice di stato 415 (tipo di supporto non supportato) è inappropriato) e la sintassi dell'entità richiesta è corretta (quindi un 400 (richiesta non valida) ) il codice di stato non è appropriato) ma non è stato in grado di elaborare le istruzioni contenute. Ad esempio, questa condizione di errore può verificarsi se un corpo di richiesta XML contiene istruzioni XML ben formate (cioè sintatticamente corrette), ma semanticamente errate.

Un duplicato nel database dovrebbe essere a 409 CONFLICT.

Consiglio di utilizzare 422 UNPROCESSABLE ENTITYper errori di convalida.

Fornisco una spiegazione più lunga dei codici 4xx qui: http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

Ecco qui:

rfc2616 # section-10.4.1 - 400 Richiesta non valida

La richiesta non è stata compresa dal server a causa di una sintassi non corretta . Il client NON DOVREBBE ripetere la richiesta senza modifiche.

rfc7231 # section-6.5.1 - 6.5.1. 400 Richiesta non valida

Il codice di stato 400 (Richiesta errata ) indica che il server non può o non elabora la richiesta a causa di qualcosa che viene percepito come un errore del client (ad es. Sintassi della richiesta non valida, framing del messaggio di richiesta non valido o instradamento della richiesta ingannevole) .

Si riferisce a casi malformati (non ben formati)!

rfc4918 - 11.2. 422 Entità non elaborabile

Il codice di stato 422 (entità non elaborabile) indica che il server
comprende il tipo di contenuto dell'entità richiesta (quindi un codice di stato 415 (tipo di supporto non supportato) è inappropriato) e la sintassi dell'entità richiesta è corretta (quindi un 400 (richiesta non valida) ) il codice di stato non è appropriato) ma non è stato in grado di elaborare le istruzioni contenute. Ad esempio, questa condizione di errore può verificarsi se un corpo di richiesta XML contiene istruzioni XML ben formate (cioè sintatticamente corrette), ma semanticamente errate .

Conclusione

Regola empirica: [_] 00 copre il caso più generale e i casi che non sono coperti dal codice designato.

422 si adatta all'errore di convalida dell'oggetto migliore (precisamente la mia raccomandazione :)
Per quanto riguarda semanticamente errato - Pensa a qualcosa come la convalida "Questo nome utente esiste già".

400 viene utilizzato in modo errato per la convalida dell'oggetto

Direi che tecnicamente potrebbe non essere un errore HTTP, poiché la risorsa è stata (presumibilmente) validamente specificata, l'utente è stato autenticato e non si sono verificati errori operativi (tuttavia anche le specifiche includono alcuni codici riservati come 402 Pagamento richiesto che non sono ' sia in termini strettamente correlati all'HTTP, anche se potrebbe essere consigliabile averlo a livello di protocollo in modo che qualsiasi dispositivo possa riconoscere la condizione).

In tal caso, aggiungerei un campo di stato alla risposta con errori dell'applicazione, ad esempio

<status><code>4</code> <message> L'intervallo di date non è valido </message> </status>

Ci sono un po 'più di informazioni sulla semantica di questi errori in RFC 2616 , che documenta HTTP 1.1.

Personalmente, probabilmente lo userei 400 Bad Request, ma questa è solo la mia opinione personale senza alcun supporto fattuale.

Cosa intendi esattamente per "errore di convalida"? Cosa stai convalidando? Ti riferisci a qualcosa come un errore di sintassi (ad esempio XML non valido)?

In tal caso, direi che 400 Bad Request è probabilmente la cosa giusta, ma senza sapere che cosa stai "convalidando", è impossibile dirlo.