400 codice BAD HTTP codice errore richiesto?

Ho una richiesta JSON che sto postando su un URL HTTP.

Questo dovrebbe essere trattato come 400dove requestedResourceesiste il campo ma "Roman"è un valore non valido per questo campo?

[{requestedResource:"Roman"}] 

Questo dovrebbe essere trattato come 400dove il "blah"campo non esiste affatto?

[{blah:"Roman"}]

Un 400 indica che la richiesta non era valida. In altre parole, il flusso di dati inviato dal client al server non ha seguito le regole.

Nel caso di un'API REST con un payload JSON, in genere 400 sono, e direi correttamente, usati per indicare che JSON non è valido in qualche modo secondo la specifica API per il servizio.

In base a tale logica, entrambi gli scenari forniti dovrebbero essere 400.

Immagina invece che fossero XML anziché JSON. In entrambi i casi, l'XML non avrebbe mai superato la convalida dello schema, a causa di un elemento indefinito o di un valore di elemento errato. Sarebbe una cattiva richiesta. Lo stesso affare qui.

Da w3.org

10.4.1 400 Richiesta non valida

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

La selezione di un codice di risposta HTTP è un'operazione piuttosto semplice e può essere descritta da semplici regole. L'unica parte difficile che viene spesso dimenticata è il paragrafo 6.5 di RFC 7231:

Tranne quando risponde a una richiesta HEAD, il server DOVREBBE inviare una rappresentazione contenente una spiegazione della situazione di errore e se si tratta di una condizione temporanea o permanente.

Le regole sono le seguenti:

1. Se la richiesta ha avuto esito positivo, restituisce il codice 2xx (3xx per il reindirizzamento). Se si è verificato un errore logico interno su un server, restituire 5xx. Se c'è qualcosa di sbagliato nella richiesta del client, quindi restituire il codice 4xx.
2. Cerca il codice di risposta disponibile dalla categoria selezionata. Se uno di loro ha un nome che si adatta bene alla tua situazione, puoi usarlo. Altrimenti basta eseguire il fallback al codice x00 (200, 400, 500). In caso di dubbi, ricorrere al codice x00.
3. Restituisce la descrizione dell'errore nel corpo della risposta. Per i codici 4xx deve contenere informazioni sufficienti per consentire allo sviluppatore del client di comprendere il motivo e correggere il client. Per 5xx per motivi di sicurezza non devono essere rivelati dettagli.
4. Se il client deve distinguere errori diversi e avere reazioni diverse a seconda di esso, definire un formato di errore leggibile ed estensibile dalla macchina e utilizzarlo ovunque nell'API. È buona pratica farlo fin dall'inizio.
5. Tieni presente che lo sviluppatore client può fare cose strane e provare ad analizzare le stringhe che restituisci come descrizione leggibile dall'uomo. E cambiando le stringhe spezzerai i client scritti così male. Quindi fornire sempre una descrizione leggibile dalla macchina e cercare di evitare di riportare informazioni aggiuntive nel testo.

Quindi nel tuo caso avevo restituito 400 errori e qualcosa del genere se "Roman" è ottenuto dall'input dell'utente e il client deve avere una reazione specifica:

{
    "error_type" : "unsupported_resource",
    "error_description" : "\"Roman\" is not supported"
}

o un errore più generico, se tale situazione è un errore logico errato in un client e non è previsto, a meno che lo sviluppatore non abbia commesso un errore:

{
    "error_type" : "malformed_json",
    "error_description" : "\"Roman\" is not supported for \"requestedResource\" field"
}

In nessuno dei due casi la "sintassi è malformata". È la semantica che è sbagliata. Quindi, IMHO a 400 è inappropriato. Invece, sarebbe opportuno restituire un 200 insieme a qualche tipo di oggetto di errore come { "error": { "message": "Unknown request keyword" } }o altro.

Considerare i percorsi di elaborazione del client. Un errore di sintassi (ad es. JSON non valido) è un errore nella logica del programma, in altre parole un bug di qualche tipo, e dovrebbe essere gestito di conseguenza, in un modo simile a un 403, diciamo; in altre parole, qualcosa di brutto è andato storto.

Un errore nel valore di un parametro, d'altra parte, è un errore di semantica, forse dovuto a un input dell'utente mal validato. Non è un errore HTTP (anche se suppongo che potrebbe essere un 422). Il percorso di elaborazione sarebbe diverso.

Ad esempio, in jQuery, preferirei non dover scrivere un singolo gestore di errori che si occupa sia di cose come 500 che di alcuni errori semantici specifici dell'app. Anche altri framework, Ember per uno, trattano gli errori HTTP come 400s e 500s identici come grandi fallimenti, richiedendo al programmatore di rilevare cosa sta succedendo e ramificarsi a seconda che si tratti di un errore "reale" o meno.

L'uso di 400codici di stato per scopi diversi dall'indicare che la richiesta non è corretta è semplicemente sbagliato.

Se il payload della richiesta contiene una sequenza di byte che non può essere analizzata come application/json(se il server prevede tale formato dati), il codice di stato appropriato è 415:

Il server rifiuta di servire la richiesta perché l'entità della richiesta è in un formato non supportato dalla risorsa richiesta per il metodo richiesto.

Se il payload della richiesta è sintatticamente corretto ma semanticamente errato, è 422possibile utilizzare il codice di risposta non standard o il 403codice di stato standard :

Il server ha compreso la richiesta, ma si rifiuta di soddisfarla. L'autorizzazione non sarà di aiuto e la richiesta NON DOVREBBE essere ripetuta.

Pensa alle aspettative.

Come app client, ti aspetti di sapere se qualcosa va storto sul lato server. Se il server deve generare un errore quando blahmanca o il requestedResourcevalore non è corretto, sarebbe appropriato un errore 400.

Come complemento, per coloro che potrebbero riscontrare lo stesso problema mio, sto usando $.ajaxper inviare i dati del modulo al server e all'inizio ho anche riscontrato l' 400errore.

Supponiamo che io abbia una variabile javascript,

var formData = {
    "name":"Gearon",
    "hobby":"Be different"
    }; 

Non utilizzare la variabile formDatadirettamente come valore della chiave datacome di seguito:

$.ajax({
    type: "post",
    dataType: "json",
    url: "http://localhost/user/add",
    contentType: "application/json",
    data: formData,
    success: function(data, textStatus){
        alert("Data: " + data + "\nStatus: " + status); 
    }
});

Invece, usa JSON.stringify per incapsulare il formDataseguente:

$.ajax({
    type: "post",
    dataType: "json",
    url: "http://localhost/user/add",
    contentType: "application/json",
    data: JSON.stringify(formData),
    success: function(data, textStatus){
        alert("Data: " + data + "\nStatus: " + status); 
    }
});

Ad ogni modo, come altri hanno illustrato, l'errore è dovuto al fatto che il server non è stato in grado di riconoscere la richiesta causando sintassi non corretta, sto solo sollevando un'istanza in pratica. Spero che sarebbe utile a qualcuno.

Prima controlla l'URL potrebbe essere sbagliato, se è corretto, quindi controlla il corpo della richiesta che stai inviando, la possibile causa è che la richiesta che stai inviando manca della sintassi corretta.

Per elaborare, verificare la presenza di caratteri speciali nella stringa di richiesta. Se viene utilizzato (carattere speciale), questa è la causa principale di questo errore.

prova a copiare la richiesta e analizza tutti i dati dei tag.