Codice di stato HTTP corretto per input errato

Qual è il codice di risposta HTTP ottimale quando non viene segnalato 200 (tutto OK) ma un errore nell'input?

Ad esempio, invii alcuni dati al server e risponderai che i tuoi dati sono errati

l'uso 500assomiglia di più a Problema server l'
utilizzo 200con testo di risposta di avviso / errore è errato (consente la memorizzazione nella cache e tutto non è OK) l'
utilizzo 204e la restituzione di nulla, è forse buono (ma ben supportato?) l'
utilizzo 404è errato se il percorso richiesto (script) è disponibile e al posto giusto

Abbiamo avuto lo stesso problema anche durante la creazione della nostra API. Stavamo cercando un codice di stato HTTP equivalente a un InvalidArgumentException. Dopo aver letto l'articolo di seguito di seguito, abbiamo finito per usare 422 Unprocessable Entityquali stati:

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.

fonte: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm

I codici che iniziano con 4 (4xx) sono pensati per errori client. Forse 400 (Bad Request) potrebbe essere adatto a questo caso? La definizione in http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html dice:

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

Oltre alle specifiche RFC è possibile vedere anche questo in azione. Dai un'occhiata alle risposte di Twitter.

https://developer.twitter.com/en/docs/ads/general/guides/response-codes

409 Conflict potrebbe essere una soluzione accettabile.

Secondo: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Impossibile completare la richiesta a causa di un conflitto con lo stato corrente della risorsa. Questo codice è consentito solo nelle situazioni in cui è previsto che l'utente possa essere in grado di risolvere il conflitto e inviare nuovamente la richiesta. Il corpo della risposta DOVREBBE includere informazioni sufficienti affinché l'utente possa riconoscere l'origine del conflitto. Idealmente, l'entità di risposta dovrebbe includere informazioni sufficienti per l'utente o l'agente utente per risolvere il problema; tuttavia, ciò potrebbe non essere possibile e non è necessario.

Il documento continua con un esempio:

È più probabile che si verifichino conflitti in risposta a una richiesta PUT. Ad esempio, se si utilizzava il controllo delle versioni e l'entità in fase di PUT includeva modifiche a una risorsa in conflitto con quelle fatte da una richiesta precedente (di terze parti), il server potrebbe utilizzare la risposta 409 per indicare che non è possibile completare la richiesta . In questo caso, l'entità della risposta conterrebbe probabilmente un elenco delle differenze tra le due versioni in un formato definito dal tipo di contenuto della risposta.

Nel mio caso, vorrei mettere una stringa, che deve essere unica, in un database tramite un'API. Prima di aggiungerlo al database, sto verificando che non sia già presente nel database.

Se lo è, tornerò "Error: The string is already in the database", 409.

Credo che questo sia ciò che l'OP voleva: un codice di errore adatto quando i dati non superano i criteri del server.

Secondo lo scenario seguente,

Diciamo che qualcuno fa una richiesta al tuo server con dati nel formato corretto, ma semplicemente non sono dati "buoni". Ad esempio, immagina che qualcuno abbia pubblicato un valore String su un endpoint API che prevedesse un valore String; ma il valore della stringa conteneva dati che erano nella lista nera (es. impedire alle persone di usare "password" come password). quindi il codice di stato potrebbe essere 400 o 422?

Fino ad ora, avrei restituito una "400 richiesta non valida", che, secondo w3.org, significa:

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

Questa descrizione non si adatta perfettamente alla circostanza; ma, se si passa dall'elenco dei codici di stato HTTP di base definiti nel protocollo HTTP / 1.1, è probabilmente la soluzione migliore.

Di recente, tuttavia, qualcuno del mio team Dev ha sottolineato [per me] che le API popolari stanno iniziando a utilizzare le estensioni HTTP per ottenere informazioni più dettagliate sulla segnalazione degli errori. In particolare, molte API, come Twitter e Recurly, utilizzano il codice di stato "422 entità non elaborabile" come definito nell'estensione HTTP per WebDAV. Il codice di stato HTTP 422 afferma:

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.

Tornando al nostro esempio di password dall'alto, questo codice di stato 422 sembra molto più appropriato. Il server capisce cosa stai cercando di fare; e comprende i dati che stai inviando; semplicemente non consentirà che tali dati vengano elaborati.

404 - Non trovato - può essere utilizzato per L'URI richiesto non è valido o la risorsa richiesta come un utente non esiste.