ruby on rails - unprocessable - ¿Es el estado HTTP 422 apropiado para los registros que fallan en la validación de unicidad?

status code 200

Question

Lo he hecho muchas veces (y he visto a muchas personas hacerlo), pero empiezo a preguntarme si es apropiado:

if @record.save
  # status 200
else
  # failure of validations => status 422
end

Ahora veo que 422 unprocessable entity significa que la solicitud estaba bien formada, pero no semánticamente correcta . Como lo entendí, un error de validación puede no ser un error semántico.

Nota: estoy hablando de validaciones de exclusividad , por lo que no estoy seguro de que esto califique como un error del usuario, como en esta pregunta: ¿Qué es un código de estado HTTP apropiado para que un servicio de REST API devuelva un error de validación?

En resumen: ¿debo dejar de usar el estado 422? Si es así, ¿qué debo usar en su lugar?

Answer 1

Estoy de acuerdo con jbbarth en que no es tan simple como 422 vs 500 .

422 es bueno para los errores de validación, pero tampoco desea capturar los errores db.

Este es el patrón que uso:

if @record.invalid?
  # failure of validations => status 422
elsif @record.save
  # status 200
else
  # failure when saving => status 500
end

Answer 2

Mientras que devolver un 422 está bien, yo diría que fallar en las validaciones de unicidad debería devolver un Conflicto 409.

Answer 3

NB: intenté hacer una respuesta detallada a continuación de Poke, pero no parece ser posible, así que responderé aquí.

Creo que usar 422 para errores de validación está bien.

1. El Webdav RFC no dice que 422 significa "errores semánticos", sino que el servidor no pudo procesar las instrucciones contenidas (consulte http://tools.ietf.org/html/rfc4918#section-11.2 ). Los "errores semánticos" se citan como un ejemplo de caso de uso.

2. 500 está reservado para "una condición inesperada que le impidió cumplir con la solicitud" ( http://tools.ietf.org/html/rfc2616#section-10.5.1 ).

Por lo general, 500 se reserva para errores reales, por ejemplo, cosas que no se manejan en absoluto en su código, como fallas. Los errores de validación se manejan, no son "inesperados" y el cliente tiene que cambiar la solicitud para que se pueda procesar (o no). En ese sentido, el cliente cometió el error (por ejemplo, enviar una dirección de correo electrónico con un formato incorrecto generará un error de validación, pero obviamente no es un error del servidor, ¿no?).

La mayoría de las API que he visto utilizan 400 o 422 para estos casos. Tal vez no haya una respuesta verdadera a esto, pero decir que 500 es la forma obvia de irme me pareció mal.

Espero que esto ayude.

Answer 4

Tengo entendido que cuando la solicitud HTTP era correcta pero fallaba en el lado del servidor, por cualquier motivo, debería lanzar un error 5xx, que indica que hubo un problema con el servidor. A menos que pueda especificarlo más, un simple 500 suele ser lo suficientemente bueno.

Si no es culpa del cliente, pero algo más (que el cliente no puede influir) impidió que se guardara el registro, entonces es un error del servidor y no un error (cliente) en el sentido de la comunicación HTTP.