¿Cómo manejar las excepciones de REST?

Estamos en medio de una discusión en curso sobre cómo manejar las excepciones de REST.¿Cómo manejar las excepciones de REST?

Respuesta Tipo de contenido: JSON

Dos soluciones que tenemos:

lanzar todas las excepciones sin marcar, como una respuesta JSON.
Enviar solicitud Código de respuesta no válida.

Argumentos:

Cuando es un error, ¿por qué volver JSON? Simplemente envíe un código de respuesta no válido.

Contador Argumento:

Código de respuesta son demasiado técnicos para manejar para los desarrolladores normales.

¿Cuál es su opinión?

Fuente

2010-06-25 Vanchinathan Chandrasekaran

Me pregunto por qué los códigos de respuesta son demasiado técnicos. Si tiene que/puede tomar cualquier acción correctiva, debe depender del código de respuesta (o de cualquier otro código de error dentro del json) y no de las cadenas de error legibles por el usuario –

. Tratamos con todo tipo de clientes. Por lo tanto, no queremos suponer que los desarrolladores con los clientes sean lo suficientemente competentes como para entender los códigos de respuesta. Ese era el pensamiento de algunas personas y el mío también. Si miran al json pueden entender el error. –

Una de las principales ventajas de REST es la uniformidad de las interfaces. Entonces, cuando dice que tenemos una APLICACIÓN REST, el cliente anticipa automáticamente la lista de recursos y las operaciones GET PUT POST DELETE y, de manera similar, conoce los códigos de error que puede imaginar. Las cadenas de error definitivamente serían útiles para que su cliente (desarrolladores) depure. Pero el código que escriben contra su API * debe * tomar medidas basadas en los códigos y no en cadenas. –

Para una API JSON desarrollé recientemente hago ambas cosas. Siempre respondo con JSON válido (bueno, supongo que respondo en absoluto). Si detecto una solicitud no válida, uso el estado 400. Si detecto un error del servidor (que no creo que sea causado por una solicitud no válida), uso un estado 5xx. El objeto JSON contiene una clave especial que solo está configurada para errores, con un valor de cadena.

Creo que esta es una buena solución que respeta los principios de REST y se puede usar de múltiples maneras. La misma solución es utilizada por otras API de JSON, como Yahoo Search. Pruebe http://search.yahooapis.com/ImageSearchService/V1/imageSearch?appid=YahooDemo&output=json.

Fuente

2010-06-25 21:46:30

+1: con un uso RESTful de HTTP, debe aprovechar los códigos de respuesta HTTP.Se puede devolver información adicional en la representación. –

Acabo de ver esta respuesta en los elementos "relacionados" de SO. Y aunque es una respuesta antigua, obviamente sigue apareciendo. Creo que hay mucho * más en el manejo de errores que simplemente usar los códigos de estado HTTP (¡lo que es un buen comienzo!). Ver http://soabits.blogspot.dk/2013/05/error-handling-considerations-and-best.html para una discusión en profundidad. –

Use códigos de error como HTTP. Así que 50 * para cualquier excepción causada por algún problema interno. Y 40 * por malos argumentos. Evite usar sus propios códigos definidos en la medida de lo posible. La idea es tener una interfaz "uniforme".

En general. 204 para el éxito sin enviar ningún contenido 200 para el éxito con una representación json del recurso Y si no es una operación exitosa, devuelva el código de respuesta apropiado. Puede elegir opcionalmente devolver un json. Para simplificar las cosas, puede tener un formato común (json) para todas las respuestas de error.

http://en.wikipedia.org/wiki/REST es una lectura obligatoria antes de congelar sus especificaciones de API.

Fuente

2010-06-25 22:07:01

"201 para tener éxito sin enviar ningún contenido". 201 se crea, por lo que solo se debe usar cuando "se crea un nuevo recurso", no para el éxito general. Usted podría estar pensando en 204, "Sin contenido" –

¡Uy! derecho. ¡gracias por la corrección! –

¿Cómo manejar las excepciones de REST?

Respuesta

Cuestiones relacionadas