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

Question

Attualmente sto restituendo 401 Non autorizzato ogni volta che si verifica un errore di convalida nell'applicazione API REST basata su Django/Piston. Avendo dato un'occhiata allo HTTP Status Code Registry Non sono convinto che questo sia un codice appropriato per un errore di convalida, cosa raccomandate?

• 400 Bad Request
• 401 non autorizzato
• 403 Forbidden
• 405 Metodo non consentito
• 406 Non accettabile
• 412 Precondizione Fallita
• 417 Expectation Failed
• 422 Unprocessable Entity
• 424 Dipendenza non riuscita

Aggiornamento: "errore di convalida" di cui sopra indica un guasto a livello di applicazione convalida dei dati, vale a dire, datetime in modo non corretto specificato, indirizzo e-mail fasullo ecc

Answer 1

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 si scopre che è nel formato sbagliato o si riferisce al 31 febbraio, allora si restituirebbe un 400 HTTP. Idem se si prevede un XML ben formato in un corpo entità e non riesce ad analizzare.

(1/2016): Nel corso degli ultimi cinque anni WebDAV 's più HTTP specifica 422 (Unprocessable Entity) è diventato un molto ragionevole alternativa al HTTP 400. Si veda ad esempio il suo utilizzo in JSON API. Notare che HTTP 422 ha non trasformato in HTTP 1.1, RFC-7231.

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

400 (“Bad Request”)
Priorità: alta.
Questo è lo stato di errore lato client generico, utilizzato quando nessun altro codice di errore 4xx è appropriato. E 'comunemente usato quando il client invia una rappresentazione insieme a un PUT o richiesta POST, e la rappresentazione è nel formato giusto, ma non fa alcun senso. (P 381.)

e:

401 (“non autorizzato”)
Priorità: alta.
Il client ha tentato di operare su una risorsa protetta senza fornire le credenziali di autenticazione corrette. Potrebbe aver fornito le credenziali sbagliate o nessuna. Le credenziali possono essere un nome utente e una password, una chiave API, o l'autenticazione token-qualunque sia il servizio in questione è in attesa. E 'comune per un cliente per fare una richiesta di un URI e accettare un 401 solo così si sa che tipo di credenziali per inviare e in quale formato. [...]

Answer 2

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

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

Answer 3

Che cosa intendi esattamente per "errore di convalida"? Cosa stai convalidando? Ti stai riferendo a qualcosa di simile a un errore di sintassi (ad esempio, XML malformato)?

Se è così, direi che 400 Bad Request è probabilmente la cosa giusta, ma senza sapere cosa si sta "validando", è impossibile dirlo.

Answer 4

Direi tecnicamente che potrebbe non essere un errore HTTP, poiché la risorsa era (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 Necessari che non sono strettamente correlati a HTTP, anche se potrebbe essere consigliabile averlo a livello di protocollo in modo che ogni dispositivo possa riconoscere la condizione).

Se questo è effettivamente il caso, vorrei aggiungere un campo di stato alla risposta con errori di applicazione, come

<stato> <codice/code> < messaggio gamma > data non è valida </messaggio > </stato >

Answer 5

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

L'(Unprocessable Entity) codice di stato 422 significa che il server capisce il tipo di contenuto dell'entità richiesta (da qui a 415 (Tipo di supporto non supportato) il codice di stato è inappropriato) e la sintassi dell'entità di richiesta è corretta (quindi un codice di stato 400 (Richiesta errata) non è appropriato) ma non è stato in grado di elaborare le istruzioni contenute. Ad esempio, questa condizione di errore può verificarsi se una richiesta corpo XML contiene ben formato (cioè sintatticamente corretto), ma semanticamente erronei, istruzioni XML.

Answer 6

Un duplicato nel database deve essere un 409 CONFLICT.

mi consiglia di utilizzare 422 UNPROCESSABLE ENTITY per errori di convalida.

mi danno una spiegazione più lunga di 4xx codici qui: http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

Answer 7

qui è:

RFC2616 # sezione-10.4.1-400 Bad Request

La richiesta non può essere compresa dal server a causa di malformati sintassi. Il cliente NON DOVREBBE ripetere la richiesta senza modifiche.

rfc7231 # sezione 6.5.1 - 6.5.1. 400 Bad Request

L'(Richiesta non valida) codice di stato 400 indica che il server non oppure può non elaborerà la richiesta a causa di qualcosa che viene percepito essere un errore di client (ad esempio, richiesta non valida la sintassi , telegramma dei messaggi di richiesta non valido o instradamento di richieste ingannevoli).

Si riferisce a casi non ben formati (non ben formati)!

rfc4918 - 11.2. 422 Unprocessable Entity

L'(Unprocessable Entity) codice di stato 422 significa che il server
capisce il tipo di contenuto dell'entità richiesta (quindi un (non supportato Tipo di carta) codice di stato 415 è inadeguato), e la sintassi l'entità richiesta è corretta (quindi un codice di stato 400 (Richiesta non valida) è inappropriato) 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 un formato ben formato (vale a dire, sintatticamente corretto), ma semanticamente errato, istruzioni XML.

Conclusione

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

adatta meglio errore di convalida oggetto (appunto la mia raccomandazione :)
Per quanto riguarda semanticamente errato - Pensate a qualcosa come "Questo nome utente esiste già" di convalida.

400 viene utilizzato in modo non corretto per la validazione oggetto