Il modo migliore per restituire messaggi di errore sui servizi REST?

Question

Ho cercato esempi di API REST come Netflix http://developer.netflix.com/docs/REST_API_Reference#0_59705 e Twitter e sembrano inserire messaggi di errore nella risposta dell'intestazione statusText invece del responseText. Stiamo sviluppando una API RESTful interna e sto discutendo per l'invio di messaggi statusText personalizzati e ignorando il responseText.

Per lo scopo della nostra app, restituiamo l'errore 400 quando l'utente ha provato a fare qualcosa che non dovrebbero, e gli unici messaggi di errore che verranno aggiornati nell'interfaccia utente per l'utente verranno consegnati con 400. Sono convinto che il messaggio debba essere inviato come status modificato. Tuttavia uno degli ingegneri (che conosce un po 'meno REST di me) sta discutendo per inviarlo nel responseText.

Qual è il modo migliore per andare?

Answer 1

Penso che tu abbia ragione, l'approccio generale è utilizzare il meccanismo di errore esistente incorporato in HTTP.

In generale, provare ad associare i propri errori agli errori HTTP esistenti, ad esempio se richiedono qualcosa a cui non hanno il permesso, restituire un errore 403.

Se chiedono qualcosa che non esiste, restituisce un 404.

• Alex

Answer 2

HTTP definisce che si dovrebbe mettere un messaggio di errore descrittivo nel corpo dell'entità di risposta, aka responseText.

statusText non viene visualizzato o elaborato da alcun client.

Vorrei usare il testo di stato per il tipo di messaggio di errore, alias 400 Client Error, e il corpo per una descrizione del problema che può essere reso all'utente, in qualunque formato il client possa essere in grado di elaborare .

Edit: Si noti che, da allora, un nuovo formato standardizzato esiste per comunicare in uno standard di dettagli dell'errore di moda al client, che potete trovare a https://tools.ietf.org/html/rfc7807 e che vi consiglio vivamente.

Answer 3

Il prelievo del codice di stato appropriato per le risposte è estremamente importante in quanto è un fattore chiave per la creazione di messaggi di auto-descrizione.

Il corpo entità dovrebbe essere una rappresentazione dello stato della risorsa e idealmente contenere collegamenti ipertestuali a disposizione Uniti il ​​prossimo nell'applicazione

Answer 4

In base alle specifiche HTTP (rfc2616): "codici di stato HTTP sono estensibili"

Tuttavia non penso che la creazione di nuovi stati per ogni diverso messaggio di errore sia l'approccio corretto:

Direi scegliere lo stato HTTP in modo appropriato (HTTP Status Code Definitions) se non riesci a trovare alcuna categoria che corrisponda al tuo requisito creane uno personalizzato (ma Sono sicuro che lo farai) e inserirò messaggi di errore nel corpo della risposta HTTP.

Answer 5

I codici di stato Http sono piuttosto auto-esplicativi e dovrebbero essere utilizzati come tali. Restituire 200 OK con errori di validazione è piuttosto Soap-y e fuorviante. Qualsiasi errore di implementazione 4xx e 5xx del client REST si inserisce in un blocco di errore e dipende in realtà, caso per caso, se si desidera utilizzare il corpo della risposta per le risposte non 2xx.