Codici di stato HTTP REST per convalida non riuscita o duplicato non valido

Sto creando un'applicazione con un'API basata su REST e sono arrivato al punto in cui sto specificando i codici di stato per ogni richiesta.

Quale codice di stato devo inviare per richieste che non hanno superato la convalida o in cui una richiesta sta tentando di aggiungere un duplicato nel mio database?

Ho cercato su http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html ma nessuno di loro sembra giusto.

Esiste una pratica comune quando si inviano codici di stato?

Per errore di convalida dell'input: 400 richiesta non valida + descrizione facoltativa. Questo è suggerito nel libro " RESTful Web Services ". Per doppio invio: 409 Conflitto

Aggiornamento giugno 2014

La specifica pertinente era RFC2616 , che forniva l'uso di 400 (Bad Request) piuttosto restrittivamente

La richiesta non è stata compresa dal server a causa di una sintassi non corretta

Quindi si sarebbe potuto sostenere che non era appropriato per errori semantici. Ma non più; da giugno 2014 la pertinente norma RFC 7231 , che sostituisce la precedente RFC2616, prevede l'uso di 400 (Bad Request) in senso lato come

il server non può o non elabora la richiesta a causa di qualcosa che viene percepito come un errore client

• Convalida non riuscita: 403 Proibito ("Il server ha compreso la richiesta, ma si rifiuta di soddisfarla"). Contrariamente all'opinione popolare, RFC2616 non dice "403 è inteso solo per l'autenticazione fallita", ma "403: so cosa vuoi, ma non lo farò". Tale condizione potrebbe essere dovuta o meno all'autenticazione.
• Tentativo di aggiungere un duplicato: 409 Conflict ("Impossibile completare la richiesta a causa di un conflitto con lo stato corrente della risorsa.")

Dovresti assolutamente dare una spiegazione più dettagliata nelle intestazioni e / o nel corpo della risposta (ad es. Con un'intestazione personalizzata - X-Status-Reason: Validation failed).

Raccomando il codice di stato 422, "Entità non elaborabile" .

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.

200.300, 400, 500 sono tutti molto generici. Se vuoi generico, 400 è OK.

422 viene utilizzato da un numero crescente di API e viene persino utilizzato da Rails immediatamente.

Indipendentemente dal codice di stato che scegli per la tua API, qualcuno non sarà d'accordo. Ma preferisco 422 perché penso che "400 + stato del testo" sia troppo generico. Inoltre, non stai sfruttando un parser pronto per JSON; al contrario, un 422 con una risposta JSON è molto esplicito e possono essere trasmesse molte informazioni di errore.

A proposito della risposta JSON, tendo a standardizzare la risposta all'errore di Rails per questo caso, che è:

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

Questo formato è perfetto per la convalida dei moduli, che considero il caso più complesso da supportare in termini di "ricchezza nella segnalazione degli errori". Se la tua struttura degli errori è questa, probabilmente gestirà tutte le tue esigenze di segnalazione degli errori.

200

Ugh ... (309, 400, 403, 409, 415, 422) ... molte risposte cercando di indovinare, discutere e standardizzare qual è il miglior codice di ritorno per una richiesta HTTP corretta ma una chiamata REST fallita .

È errato mescolare codici di stato HTTP e codici di stato REST.

Tuttavia, ho visto molte implementazioni mescolarle e molti sviluppatori potrebbero non essere d'accordo con me.

I codici di ritorno HTTP sono correlati a HTTP Requestse stesso. Una chiamata REST viene eseguita utilizzando una richiesta del protocollo di trasferimento Hypertext e funziona a un livello inferiore rispetto al metodo REST richiamato stesso. REST è un concetto / approccio e il suo output è un risultato aziendale / logico , mentre il codice risultato HTTP è un trasporto .

Ad esempio, restituendo "404 Non trovato" quando si chiama / users / è confuso, perché può significare:

• URI errato (HTTP)
• Nessun utente trovato (REST)

"403 Proibito / Accesso negato" può significare:

• È richiesta un'autorizzazione speciale. I browser possono gestirlo chiedendo l'utente / password. (HTTP)
• Autorizzazioni di accesso errate configurate sul server. (HTTP)
• Devi essere autenticato (REST)

E l'elenco potrebbe continuare con "Errore del server 500" (un errore HTTP generato da Apache / Nginx o un errore di vincolo aziendale in REST) ​​o altri errori HTTP ecc ...

Dal codice, è difficile capire quale fosse la ragione dell'errore, un errore HTTP (trasporto) o un errore REST (logico).

Se la richiesta HTTP è stata eseguita correttamente, dovrebbe sempre restituire 200 codice, indipendentemente dal record trovato o meno. Perché la risorsa URI è stata trovata ed è stata gestita dal server HTTP. Sì, potrebbe restituire un set vuoto. È possibile ricevere una pagina Web vuota con 200 come risultato HTTP, giusto?

Invece di questo puoi restituire 200 codice HTTP con alcune opzioni:

• Oggetto "errore" nel risultato JSON se qualcosa va storto
• Matrice / oggetto JSON vuota se nessun record trovato
• Un risultato bool / flag di successo in combinazione con le opzioni precedenti per una migliore gestione.

Inoltre, alcuni provider di servizi Internet potrebbero intercettare le tue richieste e restituirti un codice HTTP 404. Ciò non significa che i tuoi dati non vengano trovati, ma è qualcosa di sbagliato a livello di trasporto.

Da Wiki :

Nel luglio 2004, il fornitore di telecomunicazioni britannico BT Group ha implementato il sistema di blocco dei contenuti Cleanfeed, che restituisce un errore 404 a qualsiasi richiesta di contenuto identificata come potenzialmente illegale da Internet Watch Foundation. Altri ISP restituiscono un errore HTTP 403 "vietato" nelle stesse circostanze. La pratica di impiegare falsi errori 404 come mezzo per nascondere la censura è stata segnalata anche in Tailandia e Tunisia. In Tunisia, dove la censura era severa prima della rivoluzione del 2011, la gente divenne consapevole della natura dei falsi errori 404 e creò un personaggio immaginario chiamato "Ammar 404" che rappresenta "il censore invisibile".

Perché non rispondere semplicemente con qualcosa del genere?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

Google restituisce sempre 200 come codice di stato nell'API di geocodifica, anche se la richiesta fallisce logicamente: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

Facebook restituisce sempre 200 per le richieste HTTP riuscite, anche se la richiesta REST fallisce: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling

È semplice, i codici di stato HTTP sono per richieste HTTP. L'API REST è tua, definisci i tuoi codici di stato.

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 .

Il codice di stato 304 non modificato fornirebbe anche una risposta accettabile a una richiesta duplicata. Ciò è simile all'elaborazione di un'intestazione If-None-Matchdell'utilizzo di un tag di entità.

A mio avviso, la risposta di @ Piskvor è la scelta più ovvia a ciò che percepisco è l'intento della domanda originale, ma ho un'alternativa che è anche rilevante.

Se si desidera trattare una richiesta duplicata come un avviso o una notifica anziché come un errore, un codice dello stato della risposta di 304Non modificato e l' Content-Locationintestazione che identifica la risorsa esistente sarebbero altrettanto validi. Quando l'intento è semplicemente quello di garantire l'esistenza di una risorsa, una richiesta duplicata non sarebbe un errore ma una conferma. La richiesta non è errata, ma è semplicemente ridondante e il client può fare riferimento alla risorsa esistente.

In altre parole, la richiesta è buona, ma poiché la risorsa esiste già, il server non deve eseguire ulteriori elaborazioni.

L'adattatore ActiveRecord di Ember-Data prevede 422 UNPROCESSABLE ENTITYdi essere restituito dal server. Quindi, se il tuo client è scritto in Ember.js, dovresti usare 422. Solo allora DS.Errors verrà popolato con errori restituiti. Ovviamente puoi cambiare 422 con qualsiasi altro codice nel tuo adattatore.

406 - Non accettabile

Ciò significa che questa risposta viene inviata quando il server Web, dopo aver eseguito la negoziazione del contenuto guidata dal server, non trova alcun contenuto conforme ai criteri forniti dall'agente utente.