Ho servizio che richiede un po 'entità e ha bisogno di salvare/aggiornare questa entità:Servizio RESTful, come rispondere in caso di mancata convalida?
http://myhost.com/rest/entity
Io uso POST e inviare JSON. All'interno del servizio rileva che l'entità passata non è buona. Non valido, ordine inoltrato con cliente che non esiste, ecc.
Come devo rispondere? HttpCode.NotFound? O altri? Come rispondi a queste cose?
Nel nostro progetto in tali situazioni che facciamo la seguente:
{"message":"%extended error message here%"}ma è davvero molto soggettivo.
Inoltre suggerisco di leggere This blog article on RESTfull error handling - descrive molte opzioni disponibili, quindi è possibile scegliere qualcosa per i propri gusti.
Questo è quello che facciamo. Restituiamo lo stesso tipo di media richiesto se disponibile. Nel mondo del web si ottiene un 400 con text \ html. In questo esempio il tipo di supporto è l'applicazione \ json – suing
Grazie! Stavo pensando di passare alcune informazioni nell'intestazione oltre al codice di stato ma tra l'articolo che hai indicato e questo post penso che deciderò sull'oggetto di risposta comune per i miei servizi e userei solo 400 e 200 codici (Altro di 401 per l'autenticazione) – katit
Penso che dovresti scegliere uno client error code. 400 Richiesta o 403 Forbidden può essere un buon punto di partenza
418 è la scelta ovvia lì. –
403 non è appropriato per lo scenario descritto. –
Perché il 403 non è appropriato? http://stackoverflow.com/a/3290369/59639 Sembra che ci siano diverse scuole su 400 vs 403 –
422 Unprocessable Entity, defined in WebDAV (RFC 4918):
L'(Unprocessable Entity) codice di stato 422 significa che il server capisce il tipo di contenuto dell'entità richiesta (quindi un 415 Il codice di stato (Tipo di supporto non supportato) non è appropriato) e la sintassi dell'entità di richiesta è corretta (quindi un codice di stato 400 (Richiesta non valida) 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 (vale a dire, sintatticamente corrette), ma semanticamente errate.
Mi piace molto questo. Probabilmente sarà impopolare con i puristi, ma è molto meglio usare lo stesso stato di una richiesta malformata. –
Sul progetto a cui sto lavorando ero anche molto infastidito dall'incapacità del client di distinguere tra errori di convalida e richieste errate dal solo codice di stato (senza ispezionare il corpo della risposta), e pensavo indipendentemente di usare 422 per distinguere l'ex. Mi sono imbattuto in questo mentre eseguivo un controllo di integrità per assicurarmi che non ci fossero alternative migliori, quindi sono contento di vedere che altre persone hanno usato questo approccio e che questo non è completamente fuori dal campo sinistro.Posso presumere che nessuno di voi abbia incontrato altri problemi a valle con questo approccio? – rscarter
Bene, questo dipende davvero da voi, è il vostro servizio. – jgroenen
possibile duplicazione di [codici di stato HTTP REST per convalida non riuscita o duplicato non valido] (http://stackoverflow.com/questions/3290182/rest-http-status-codes-for-failed-validation-or-invalid-duplicate) – MaxiWheat