Codice di risposta REST per dati non validi

Quale codice di risposta deve essere passato al client in caso di scenari seguenti?

1. Dati non validi trasmessi durante la registrazione dell'utente come formato email errato
2. Nome utente / Email già esistente

Ho scelto 403. In seguito ho anche scoperto che posso usare.

Wikipedia:

412 Condizione preliminare non riuscita: il server non soddisfa una delle condizioni preliminari che il richiedente ha inserito nella richiesta

Suggerisci un codice se dovessi usare altro che 403.

400 è la scelta migliore in entrambi i casi. Se si desidera chiarire ulteriormente l'errore, è possibile modificare la Frase motivo o includere un corpo per spiegare l'errore.

412 - La condizione preliminare non riuscita viene utilizzata per le richieste condizionali quando si utilizzano la data e gli ETag dell'ultima modifica.

403 - Proibito viene utilizzato quando il server desidera impedire l'accesso a una risorsa.

L'unica altra scelta possibile è 422 - Entità non elaborabile.

Consiglierei 422. Non fa parte delle specifiche HTTP principali, ma è definito da uno standard pubblico (WebDAV) e dovrebbe essere trattato dai browser come qualsiasi altro codice di stato 4xx.

Da RFC 4918 :

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.

Se la richiesta non può essere analizzata correttamente (inclusa l'entità / il corpo della richiesta), la risposta appropriata è 400 Richiesta non valida [ 1 ].

RFC 4918 afferma che 422 entità non trasformabile è applicabile quando l'entità richiesta è sintatticamente ben formata, ma semanticamente errata. Quindi, se l'entità della richiesta è confusa (come un formato e-mail non valido) usa 400; ma se non ha senso (come @example.com) usa 422.

Se il problema è che, come indicato nella domanda, il nome utente / e-mail esiste già, potresti utilizzare 409 Conflict [ 2 ] con una descrizione del conflitto e un suggerimento su come risolverlo (in questo caso, "scegli un nome utente / email diversi "). Tuttavia, nelle specifiche scritte, 403 Forbidden [ 3 ] può essere utilizzato anche in questo caso, nonostante gli argomenti sull'autorizzazione HTTP.

412 Precondizione non riuscita [ 4 ] viene utilizzata quando un'intestazione della richiesta di precondizione (ad es. If-Match) Fornita dal client viene valutata come falsa. Cioè, il cliente ha richiesto qualcosa e fornito precondizioni, sapendo benissimo che tali presupposti potrebbero fallire. 412 non dovrebbe mai essere generato sul client di punto in bianco e non dovrebbe essere correlato all'entità richiesta di per sé .

È divertente tornare 418 I'm a teapota richieste che sono ovviamente predisposte o dannose e "non possono accadere", come il mancato controllo del CSRF o le proprietà della richiesta mancanti.

2.3.2 418 Sono una teiera

Qualsiasi tentativo di erogare caffè con una teiera dovrebbe comportare il codice di errore "418 I'm a teapot". Il corpo dell'entità risultante può essere corto e robusto.

Per mantenerlo ragionevolmente serio, limito l'uso di codici di errore divertenti agli endpoint RESTful che non sono direttamente esposti all'utente.