Codice di risposta REST per dati non validi


272

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.



Sto risolvendo anche questo problema. Il capitolo 7.Valida delle specifiche JAX-RS (2017) fornisce consigli sul codice di stato specificamente per le violazioni dei vincoli. download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-spec/…
burntsugar

Risposte:


298

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.


10
mentre viene spesso utilizzato in questo contesto, 403 non si limita al controllo di accesso, poiché rfc2616-10.4.4 dice: "Il server ha compreso la richiesta, ma si rifiuta di soddisfarla. [...] se il server desidera effettuare pubblico perché la richiesta non è stata soddisfatta, DOVREBBE descrivere il motivo del rifiuto nell'entità. " Il motivo può essere dati non validi. Tuttavia, 422 è più applicabile qui.
Yannick Loiseau,

7
Non lasciamoci prendere dalle critiche testuali. Vedi ad esempio trac.tools.ietf.org/wg/httpbis/trac/ticket/294 che tenta di chiarire che il 403 riguarda e riguardava sempre l'autorizzazione.
fumanchu,

2
@fumanchu Bella cattura. Un collegamento a una richiesta di modifica che ha solo 7 ore :-)
Darrel Miller

1
@fumanchu Significa che 403 dovrebbe essere restituito nel caso in cui l'utente non abbia il permesso di accedere alla risorsa richiesta. Ma penso che 401 Unuthorized sia più appropriato per accedere a una risorsa su cui l'utente non ha l'autorizzazione.
Amit Patel,

1
401 Non autorizzato richiederà a un browser Web di mostrare all'utente il nome utente / password HTTP standard. Se non stai utilizzando quel tipo di autenticazione per il tuo servizio o se l'utente ha già l'autenticazione HTTP, 401 non è appropriato.
Greg Ball,

92

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.


20
Si noti che il testo citato afferma che 422 è applicabile quando l'entità richiesta è sintatticamente ben formata, ma semanticamente errata. Se l'entità richiesta è confusa, 400 è la risposta appropriata.
Matty K,

87

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é .


1
Dovrei notare le RFC HTTP / 1.1 aggiornate: 400 Bad Request, 409 Conflict, 403 Forbidden etc. live in tools.ietf.org/html/rfc7231 ; 412 Precondition Failed è in tools.ietf.org/html/rfc7232#section-4.2
Matty K

41

È 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.


11
Implementalo in modo tale che l'API ritorni 418 I'm a teapotper tutte le richieste provenienti dal tuo capo :)
vikarjramun,

2
@vikarjramun ho creato un REST fittizio e ne ho reso uno prudente offline. (pre-release) ora i nostri studenti stanno cercando di creare richieste di dati valide ma è tutto teiera. Sono il "capo", ma funziona anche.
LenglBoy,

2
Questo RFC è stupido. Puoi preparare il caffè in una teiera, purché lo versi nella tazza con un colino da tè. Proprio come usare il tè sfuso. Puoi anche preparare il tè in una caffetteria senza problemi.
Gburton,

2
@gburton Ciò richiede l'intervento di un essere umano, però. Sulla rete, hai sicuramente bisogno di un dispositivo capace di preparare il caffè. Certo, un caffè-teiera non dovrebbe rispondere con un 418.
Jasper
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.