verbos ventajas una sirve qué para ejemplo arquitectura validation rest http-status-codes

validation - ventajas - ¿Qué es un código de estado HTTP apropiado para que un servicio de API REST devuelva una falla de validación?



ventajas api rest (7)

Actualmente estoy devolviendo 401 No autorizado cuando encuentro una falla de validación en mi aplicación REST API basada en Django / Piston . Habiendo echado un vistazo al Registro de Código de Estado HTTP, no estoy convencido de que este sea un código apropiado para un error de validación, ¿qué recomiendan?

  • 400 Petición Incorrecta
  • 401 no autorizado
  • 403 Prohibido
  • Método 405 no permitido
  • 406 no aceptable
  • 412 condición previa 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 la aplicación, es decir, fecha y hora incorrectamente especificadas, dirección de correo electrónico falsa, etc.

¿Qué quiere decir exactamente con "fallo de validación"? ¿Qué estás validando? ¿Se refiere a algo 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.

Aquí está:

rfc2616 # section-10.4.1 - 400 Solicitud incorrecta

El servidor no pudo comprender la solicitud debido a una sintaxis mal formada . 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 errónea) 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 mal formada, trama de mensajes de solicitud no válida o enrutamiento de solicitud engañosa) .

Se refiere a casos mal formados (no bien formados)!

rfc4918 - 11.2. 422 Entidad no procesable

El código de estado 422 (entidad no procesable) significa que el servidor
entiende 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 código de estado 400 (Solicitud incorrecta) es inapropiado) pero no pudo procesarse 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 de oro: [_] 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 lo semánticamente erróneo, piense en algo así como la validación "Este nombre de usuario ya existe".

400 se utiliza incorrectamente para la validación de objetos

De 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 entiende el tipo de contenido de la entidad de solicitud (por lo tanto, un código de estado 415 (tipo de medio no admitido) es inadecuado), y la sintaxis de la entidad de solicitud es correcta (por lo tanto, un código de estado 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.

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 usaría 400 Bad Request , pero esta es solo mi opinión personal sin ningún apoyo fáctico.

Si "error de validación" significa que hay algún error del cliente en la solicitud, entonces use HTTP 400 (Solicitud incorrecta). Por ejemplo, si se supone que el URI debe tener 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. Igual si espera un XML bien formado en el cuerpo de una entidad y no se puede analizar.

(1/2016): En los últimos cinco años, la HTTP 422 (Entidad no procesable) más específica de WebDAV ha convertido en una alternativa muy razonable a HTTP 400. Consulte, por ejemplo, su uso en la API de JSON . Pero tenga en cuenta que HTTP 422 no lo ha hecho 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 Petición Incorrecta")
Importancia: Alta.
Este es el estado de error genérico del cliente, que se utiliza 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 está en el formato correcto, pero no tiene ningún 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 una contraseña, una clave de API o un token de autenticación, independientemente de lo que el servicio en cuestión esté esperando. Es común que un cliente realice una solicitud de URI y acepte un 401 solo para que sepa qué tipo de credenciales enviar y en qué formato. [...]

Yo diría que técnicamente puede que no sea un error de HTTP, ya que el recurso fue (presumiblemente) especificado de manera válida, el usuario fue autenticado, y no hubo un error operacional (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 recomendable tenerlo 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 aplicación, como

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