18

Ho una risorsa come questa vendite/clienti/{customerno}. Se un client invia una richiesta PUT a questa risorsa, restituirei 400 - Richiesta non valida se l'xml nel corpo dell'entità non è valido xml. Ma cosa succede se l'xml è valido, ma il contenuto di xml non è valido. Supponiamo ad esempio che il cliente stia cercando di aggiornare i clienti PostCode e stia fornendo un codice postale che non è valido. È corretto restituire 400 - Richiesta errata in questo caso, o è un altro codice http che avrei dovuto usare?REST - Quando utilizzare 400 ("Richiesta errata")

risposta

24

Da Wikipedia's List of HTTP Status Codes:

400 Bad Request: La richiesta non può essere soddisfatta a causa di sintassi male.

In questo caso, il client ha inviato un payload XML con un codice postale non valido, che è una forma di sintassi non valida; pertanto, l'invio di 400 Bad Request è un codice di errore appropriato da restituire in questa situazione.

Inoltre, Wikipedia cita RFC-4918 come risorsa su questo argomento. Da questo documento, troverete le seguenti informazioni:

Server può rifiutare le richieste discutibili (anche se Consistono XML ben formato), per esempio, con una (Bad Request) codice di stato 400 e un corpo di risposta opzionale che spiega il problema .

Dal momento che la richiesta è ben formato (XML non è male, contiene solo le informazioni semanticamente corretto) si può respingere il contenuto con codice di stato 400. La parola *may* suggerisce che ci sono altre opzioni.

Mentre si potrebbe essere tentati di utilizzare il codice di stato 422, questo non sarebbe corretto in questa situazione, poiché il codice di avviamento postale non valido soddisfa i criteri per essere un errore semantico. Leggi qui sotto ...

Da Wikipedia:

422 Unprocessable Entity (WebDAV; RFC 4918): era ben formato la richiesta ma non è riuscito a seguire a causa di errori semantici.

Inoltre, qui alcune definitions to assist in the interpretation of status code 422:

  • errori di sintassi si verificano durante l'analisi di codice in ingresso, e sono causati da dichiarazioni grammaticalmente scorrette. Gli errori tipici potrebbero essere un carattere non valido nell'input, un operatore mancante, due operatori in una riga, due istruzioni sulla stessa riga senza punto e virgola, parentesi sbilanciate, una parola riservata errata, ecc.

  • Errori semantici si verificano durante l'esecuzione del codice, dopo che è stato analizzato come grammaticalmente corretto. Questi devono non fare come vengono costruite le affermazioni, ma con ciò che intendono. Cose come tipi di variabili o dimensioni errate, variabili inesistenti, pedici fuori intervallo e simili, sono errori semantici.

il CAP non valida non è né un errore di sintassi, né un errore semantico; quindi, è ragionevole escludere il codice di stato 422 come opzione.

Per rispondere alla tua domanda, il codice di stato 400 è appropriato; tuttavia, potresti avere anche altre opzioni.

+0

E le altre opzioni sono? –

+2

Ho trovato questo utile, ma sono un po 'confuso dalla conclusione. Comprendo che esiste una definizione di "semantica" di informatica che differisce dal suo uso generale. Al di fuori dell'informatica, un codice di avviamento postale non valido potrebbe effettivamente essere definito un errore semantico in questo contesto. Ho il sospetto che tu abbia ragione sul fatto che RFC lo abbia inteso specificamente nel senso scientifico del computer, ma quanto potrebbe mai essere utile un tale errore? In effetti, come potrebbe essere un errore * client *, allora? – Semicolon

+0

@Semicolon - La mia comprensione è che se l'XML fosse ben formato ma il codice di avviamento postale non rientra nell'intervallo, ciò corrisponderebbe alla definizione nell'ultimo punto elenco. Negli Stati Uniti, 123456 sarebbe un pessimo codice postale, ad esempio, ma non sarebbe un XML non valido. Un errore che dice "400 Richiesta errata - Inserisci un codice postale valido" potrebbe essere utile se rispedito al cliente. Spero che questo ti aiuti. – jmort253

17

La versione rivista della specifica HTTP trovata here ha aggiornato la dicitura per cercare di evitare questa confusione sul fatto che 400 si limiti a richieste solo malformate.

7.4.1. 400 Bad Request

Il server non può o non elabora la richiesta, a causa di un errore del client (ad esempio, sintassi errata).

+0

Il codice 400 include anche id's nel payload di cui l'utente non è proprietario della risorsa? – Elisabeth

+0

@Elisabeth Non sono sicuro di comprendere appieno il tuo scenario, ma penso che la risposta sia sì. –

+0

Lo scenario è un carico utile con ID di chiavi esterne che appartengono a un altro utente. L'eliminazione di tali ID sul server eliminerebbe le risorse di un altro utente. Sarebbe davvero pessimo. – Elisabeth

Problemi correlati