¿Cuáles son las mejores prácticas para enviar respuestas de error en servicios web JSON?

Question

¿Cuál es la mejor práctica con respecto al envío de respuestas de error en un servicio web JSON? Lo he visto de varias maneras y quería saber si había alguna norma acordada o mejores prácticas entre las opciones.

Lo he visto hecho cuando la respuesta incluye indicación de éxito o falla, así como los datos que se devolverán o un mensaje de error adecuado, p.

[{'success':true, 'data':{...}] 
[{'success':false, 'data':{'message':'error'}] 

Pero también he visto ejemplos en los que el objeto JSON sólo incluye datos y el servicio utiliza los códigos de error HTTP normales para indicar un problema (403, 404, 500, etc.). (Así es como lo hace la API de Twitter.)

¿Hay una manera "correcta" de hacerlo, o es solo una cuestión de estilo? ¿El último método es más "RESTful"?

Answer 1

En un enfoque "RESTful", la respuesta de error principal se indica mediante un código de estado apropiado (4xx/5xx).

Su mensaje debe proporcionar sugerencias adicionales, específicas de la aplicación sobre cómo recuperarse del error. Esto puede incluir representaciones legibles por humanos del error que ha ocurrido o algún tipo de indicador más técnico (es decir, que proporciona un nombre de clase de excepción).

Para ser genérico, mantenga una sintaxis de corrección para sus mensajes de error. Esto le permite introducir nuevos mensajes de error sin romper los clientes.

Answer 2

Utilice los códigos HTTP apropiados y ponga lo que ahora llama "datos" como el cuerpo de la respuesta. Esta es la única forma CORRECTAMENTE RESTANTE de avisar a los usuarios de API de un error.

Simplemente haciendo esto no hará que su API RESTful, pero no hacerlo seguramente hará que su API no RESTful.

Un ejemplo de códigos de estado HTTP bien utilizados para errores está en el Dropbox API reference, eche un vistazo a las secciones de "Errores" debajo de cada método, explique qué códigos de error debe esperar y cuál es el significado asociado en ese particular método.