¿Qué es un código de estado HTTP apropiado para devolver por un servicio API REST para una falla de validación?

Actualmente estoy devolviendo 401 sin autorización cada vez que encuentro un error de validación en mi aplicación REST API basada en Django / Piston . Después de haber examinado el Registro de códigos de estado HTTP, no estoy convencido de que este sea un código apropiado para una falla de validación, ¿qué recomiendan?

• 400 Petición Incorrecta
• 401 no autorizado
• 403 prohibido
• Método 405 no permitido
• 406 no aceptable
• 412 Precondición fallida
• 417 Expectativa fallida
• 422 Entidad no procesable
• 424 Dependencia fallida

Actualización : "Error de validación" anterior significa un error de validación de datos a nivel de aplicación, es decir, fecha y hora incorrecta, dirección de correo electrónico falsa, etc.

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

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

Los servicios web RESTful de Richardson y Ruby contienen un apéndice muy útil sobre cuándo usar los diversos códigos de respuesta HTTP. Ellos dicen:

400 ("Solicitud incorrecta")
Importancia: Alta.
Este es el estado de error genérico del lado del cliente, que se utiliza cuando ningún otro código de error 4xx es apropiado. Se usa comúnmente cuando el cliente envía una representación junto con una solicitud PUT o POST, y la representación está en el formato correcto, pero no tiene ningún sentido. (pág. 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. Las credenciales pueden ser un nombre de usuario y una contraseña, una clave API o un token de autenticación, sea lo que sea lo que el servicio en cuestión esté esperando. Es común que un cliente solicite un URI y acepte un 401 solo para saber qué tipo de credenciales enviar y en qué formato. [...]

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

El código de estado 422 (entidad no procesable) significa que el servidor comprende el tipo de contenido de la entidad de solicitud (por lo tanto, 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 400 (solicitud incorrecta) ) el código de estado es inapropiado) pero no pudo procesar las instrucciones contenidas. 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.

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

Recomiendo usar 422 UNPROCESSABLE ENTITYpara errores de validación.

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

Aquí está:

rfc2616 # section-10.4.1 - 400 Solicitud incorrecta

El servidor no pudo entender la solicitud debido a una sintaxis incorrecta . El cliente NO DEBE repetir la solicitud sin modificaciones.

rfc7231 # sección-6.5.1 - 6.5.1. 400 Petición Incorrecta

El código de estado 400 (Solicitud incorrecta) indica que el servidor no puede o no procesará la solicitud debido a algo que se percibe como un error del cliente (por ejemplo, sintaxis de solicitud con formato incorrecto, enmarcado de mensaje de solicitud no válido o enrutamiento de solicitud engañoso) .

¡Se refiere a casos malformados (no bien formados)!

rfc4918 - 11.2. 422 Entidad no procesable

El código de estado 422 (entidad no procesable) significa que el servidor
comprende el tipo de contenido de la entidad de solicitud (por lo tanto, 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 400 (solicitud incorrecta) ) el código de estado es inapropiado) pero no pudo procesar las instrucciones contenidas. 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 .

Conclusión

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

422 encaja mejor error de validación de objeto (precisamente mi recomendación :)
En cuanto a semánticamente erróneo - Piense en algo como la validación "Este nombre de usuario ya existe".

400 se usa incorrectamente para la validación de objetos

Diría que técnicamente podría no ser un error de HTTP, ya que el recurso se especificó (presumiblemente) de manera válida, el usuario se autenticó y no hubo ningún error operativo (sin embargo, incluso la especificación incluye algunos códigos reservados como 402 Pago requerido, que no son t estrictamente hablando relacionado con HTTP, aunque podría ser aconsejable tener eso a nivel de protocolo para que cualquier dispositivo pueda reconocer la condición).

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

<status><code>4</code> <message> El rango de fechas no es válido </message> </status>

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

Personalmente, probablemente lo usaría 400 Bad Request, pero esta es solo mi opinión personal sin ningún respaldo fáctico.

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

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