codigos - http status 400

¿Aparece el mensaje de error en el encabezado HTTP o en el cuerpo de respuesta?

Question

Tengo un servicio REST que está expuesto a clientes de iPhone y Android. Actualmente sigo los códigos HTTP 200, 400, 401, 403, 404, 409, 500, etc.

Mi pregunta es ¿dónde está el lugar recomendado para poner la razón / descripción / causa del error? ¿Tiene más sentido que la API REST siempre tenga un motivo personalizado en el encabezado, como tal?

< HTTP/1.1 400 Bad Request - Missing Required Parameters.
< Date: Thu, 20 Dec 2012 01:09:06 GMT
< Server: Apache/2.2.22 (Ubuntu)
< Connection: close
< Transfer-Encoding: chunked

¿O es mejor tenerlo en el Cuerpo de respuesta a través de JSON?

< HTTP/1.1 400 Bad Request
< Date: Thu, 20 Dec 2012 01:09:06 GMT
< Server: Apache/2.2.22 (Ubuntu)
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: application/json
{ "error" : "Missing Required Parameters" }

Answer 1

Citando de la especificación HTTP los códigos de error 400.x:

El código de estado de la clase 4xx está destinado a los casos en los que el cliente parece haber cometido un error. Excepto cuando se responde a una solicitud HEAD, el servidor DEBERÍA incluir una entidad que contenga una explicación de la situación de error, y si se trata de una condición temporal o permanente. Estos códigos de estado son aplicables a cualquier método de solicitud. Los agentes de usuario DEBERÍAN mostrar cualquier entidad incluida al usuario.

Es una buena práctica incluir el mensaje de error como una entidad en el cuerpo de la respuesta HTTP, ya sea JSON, texto plano, HTML formateado o cualquier otro formato que desee utilizar.

Answer 2

Es mejor tener detalles de error en el cuerpo. Además, muchos (la mayoría / casi todos, por ejemplo, WSGI) servidores y clientes no admiten cambiar el nombre del código de error; trátelos como pares fijos (por ejemplo, 400 siempre es "Solicitud incorrecta" y no "Solicitud incorrecta"). Olvidé especificar el ID de usuario "). Incluso si no se rompen, no les importará su nombre especial para un código de error específico.

Answer 3

Siempre hago las dos cosas. Por lo general, establezco el mensaje de estado en algo que la interfaz puede mostrar de forma amigable para el usuario, como "409 - No se pudo agregar el nuevo usuario, estos ya existen".

Luego incluyo los detalles de las condiciones de error en el cuerpo como JSON para que los desarrolladores de UI puedan intentar hacer elecciones inteligentes sobre qué hacer.

{
"status": 409,
"message": "The user <username> was already added on <when> by <who> and given the user id 12345.",
"errors": {
"id": 12345
}
}