¿Cuál es el código de estado HTTP apropiado que debe devolver un servicio API REST para una falla de validación?

Question

Actualmente estoy devolviendo 401 no autorizado cada vez que encuentro un error de validación en mi Django/Piston basada en la aplicación REST API. Después de echar un vistazo a HTTP Status Code Registry No estoy seguro de que este sea un código apropiado para una falla de validación, ¿qué recomiendan?

• 400 Bad Request
• 401 no autorizado
• 403 Prohibido
• 405 Método no permitido
• 406 No Aceptable
• 412 Error de condición previa
• 417 Error de expectativa
• 422 Entidad no procesable
• 424 Dependencia Error

actualización: "error de validación" anterior significa un fallo de nivel de aplicación de validación de datos, es decir, fecha y hora especificado incorrectamente, dirección de correo electrónico falso, etc.

Answer 1

Si "falla de validación" significa que hay algún error de cliente en la solicitud, entonces use HTTP 400 (Solicitud incorrecta). Por ejemplo, si se supone que el URI tiene una fecha ISO-8601 y usted encuentra que está en el formato incorrecto o se refiere al 31 de febrero, entonces usted devolvería un HTTP 400. Lo mismo si espera un XML bien formado en un cuerpo de entidad y no puede analizar.

(1/2016): En los últimos cinco años WebDAV es más específico HTTP 422 (Entidad no procesable) se ha convertido en una alternativa muy razonable a HTTP 400. Consulte por ejemplo su uso en JSON API. Pero tenga en cuenta que HTTP 422 tiene no hecho en HTTP 1.1, RFC-7231.

Richardson y Ruby's RESTful Web Services contienen un apéndice muy útil sobre cuándo usar los diversos códigos de respuesta HTTP. Dicen:

400 (“Bad Request”)
Importancia: Alta.
Este es el estado de error genérico del lado del cliente, utilizado cuando no es apropiado ningún otro código de error 4xx. Se usa comúnmente cuando el cliente envía una representación junto con una solicitud PUT o POST , y la representación tiene el formato correcto, pero no hace que tenga sentido. (P 381.)

y:

401 (“no autorizado”)
Importancia: Alta.
El cliente intentó operar en un recurso protegido sin proporcionar las credenciales de autenticación adecuadas. Puede haber proporcionado las credenciales incorrectas, o ninguna en absoluto. Las credenciales pueden ser un nombre de usuario y contraseña, una clave API o un token de autenticación , lo que sea que el servicio en cuestión esté esperando. Es común que un cliente haga una solicitud de URI y acepte un 401 para que sepa qué tipo de credenciales enviar y en qué formato. [...]

Answer 2

Hay un poco más de información acerca de la semántica de estos errores en RFC 2616, que documenta HTTP 1.1.

Personalmente, probablemente usaría 400 Bad Request, pero esta es solo mi opinión personal sin ningún tipo de apoyo real.

Answer 3

¿Qué quiere decir exactamente con "falla de validación"? ¿Qué estás validando? ¿Te refieres a algo así como un error de sintaxis (por ejemplo, XML mal formado)?

Si ese es el caso, diría que 400 Bad Request es probablemente lo correcto, pero sin saber qué es lo que "valida", es imposible decirlo.

Answer 4

Diría que técnicamente podría no ser una falla HTTP, ya que el recurso (presumiblemente) se validó, el usuario fue autenticado y no hubo falla operacional (sin embargo, incluso la especificación incluye algunos códigos reservados como 402 Payment Obligatorio que tampoco está estrictamente relacionado con HTTP, aunque podría ser aconsejable tenerlo en el nivel de protocolo para que cualquier dispositivo pueda reconocer la condición).

Si ese es realmente el caso, me gustaría añadir un campo de estado de la respuesta con errores de aplicación, como

<estado> < código/Código > < mensaje gama > fecha no es válida </mensaje > </estado >

Answer 5

De RFC 4918 (y también documentado en http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml):

El (Entidad no procesable) código de estado 422 significa que el servidor entiende el tipo de contenido de la entidad de solicitud (de ahí un código de estado 415 (Tipo de medio no admitido) es inapropiado y la sintaxis de la entidad de solicitud es correcta (por lo tanto, un código de estado 400 (Solicitud incorrecta) es inadecuado) pero no pudo procesar las instrucciones . Por ejemplo, esta condición de error puede ocurrir si un cuerpo de solicitud XML contiene instrucciones XML bien formadas (es decir, sintácticamente correctas), pero semánticamente erróneas.

Answer 6

Un duplicado en la base de datos debe ser 409 CONFLICT.

Recomiendo usar 422 UNPROCESSABLE ENTITY para errores de validación.

que dar una explicación más larga de códigos 4xx aquí: http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

Answer 7

aquí está:

RFC2616 # sección 10.4.1 - 400 Bad Request

La solicitud no pudo ser entendido por el servidor debido a malformación sintaxis. El cliente NO DEBE repetir la solicitud sin modificaciones.

rfc7231 # section-6.5.1 - 6.5.1. 400 Bad Request

El (Bad Request) código de estado 400 indica que el servidor no puede o no procesará la solicitud debido a algo que se percibe ser un error del cliente (por ejemplo, la sintaxis de solicitud mal formada , enrutamiento de mensaje de solicitud no válido o enrutamiento de solicitud engañosa).

Se refiere a casos malformados (no bienformados)!

rfc4918 - 11.2. 422 Entidad no procesable

El (Entidad no procesable) código de estado 422 significa que el servidor
entiende el tipo de contenido de la entidad de solicitud (de ahí un (no admitido Tipo de soporte) código de estado 415 es inapropiada), y la sintaxis de la entidad de solicitud es correcta (por lo tanto, un código de estado 400 (Solicitud incorrecta) es inadecuado) pero no pudo procesar las instrucciones contenidas. Por ejemplo, esta condición de error puede ocurrir si un cuerpo de solicitud XML contiene bien formado (es decir, sintácticamente correcto), pero semánticamente erróneo, instrucciones XML.

Conclusión

Regla de oro: [_] 00 cubre el caso más general y casos que no están cubiertos por el código designado.

mejor se adapte a error de validación de objeto (precisamente mi recomendación :)
En cuanto a semánticamente errónea - pensar en algo así como "Este nombre de usuario ya existe" validación.

400 se usa incorrectamente para la validación objeto