Código de respuesta REST para datos no válidos


272

¿Qué código de respuesta se debe pasar al cliente en caso de los siguientes escenarios?

  1. Datos no válidos pasados ​​durante el registro del usuario como formato de correo electrónico incorrecto
  2. Nombre de usuario / correo electrónico ya existe

Elegí 403. También encontré lo siguiente que siento que se puede usar.

Wikipedia:

412 Precondición fallida: el servidor no cumple con una de las condiciones previas que el solicitante puso en la solicitud

Sugiere un código si debo usar otro que no sea 403.



Estoy resolviendo este problema también. El Capítulo 7. Validación de la especificación JAX-RS (2017) proporciona consejos sobre el código de estado específicamente para infracciones de restricciones. download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-spec/…
burntsugar

Respuestas:


298

400 es la mejor opción en ambos casos. Si desea aclarar más el error, puede cambiar la Frase de razón o incluir un cuerpo para explicar el error.

412 - La condición previa fallida se usa para solicitudes condicionales cuando se usa la fecha de última modificación y ETags.

403 - Prohibido se usa cuando el servidor desea impedir el acceso a un recurso.

La única otra opción posible es 422 - Entidad no procesable.


10
Si bien se usa a menudo en este contexto, 403 no se limita al control de acceso, ya que rfc2616-10.4.4 dice: "El servidor entendió la solicitud, pero se niega a cumplirla. [...] si el servidor desea realizarla público por qué la solicitud no se ha cumplido, DEBE describir el motivo del rechazo en la entidad ". El motivo puede ser información no válida. Sin embargo, 422 es más aplicable aquí.
Yannick Loiseau

77
No nos dejemos atrapar por la crítica textual. Ver, por ejemplo, trac.tools.ietf.org/wg/httpbis/trac/ticket/294 que intenta aclarar que 403 es y siempre fue sobre autorización.
fumanchu

2
@fumanchu Buena captura. Un enlace a una solicitud de cambio que tiene solo 7 horas de antigüedad :-)
Darrel Miller

1
@fumanchu Significa que debe devolverse 403 en caso de que el usuario no tenga permiso para acceder al recurso solicitado. Pero creo que 401 no autorizado es más apropiado para acceder a recursos en los que el usuario no tiene permiso.
Amit Patel

1
401 No autorizado solicitará a un navegador web que muestre al usuario el aviso de nombre de usuario / contraseña HTTP estándar. Si no está utilizando ese tipo de autenticación para su servicio, o si el usuario ya tiene autenticación HTTP, 401 no es apropiado.
Greg Ball

92

Recomendaría 422. No es parte de la especificación HTTP principal, pero está definido por un estándar público (WebDAV) y debe ser tratado por los navegadores de la misma manera que cualquier otro código de estado 4xx.

Desde RFC 4918 :

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.


20
Tenga en cuenta que el texto citado indica que 422 es aplicable cuando la entidad de solicitud está sintácticamente bien formada, pero semánticamente errónea. Si la entidad de solicitud es ilegible, 400 es la respuesta apropiada.
Matty K

87

Si la solicitud no se pudo analizar correctamente (incluida la entidad / cuerpo de la solicitud), la respuesta apropiada es 400 Solicitud incorrecta [ 1 ].

RFC 4918 establece que 422 Entidad no procesable es aplicable cuando la entidad de solicitud está sintácticamente bien formada, pero semánticamente errónea. Entonces, si la entidad de solicitud es ilegible (como un formato de correo electrónico incorrecto) use 400; pero si simplemente no tiene sentido (como @example.com) use 422.

Si el problema es que, como se indica en la pregunta, el nombre de usuario / correo electrónico ya existe, puede usar 409 Conflict [ 2 ] con una descripción del conflicto y una pista sobre cómo solucionarlo (en este caso, "elija un nombre de usuario / correo electrónico diferente "). Sin embargo, en la especificación escrita, 403 Prohibido [ 3 ] también se puede utilizar en este caso, a pesar de los argumentos sobre la Autorización HTTP.

412 Precondition Failed [ 4 ] se usa cuando un encabezado de solicitud de precondición (por ejemplo If-Match) que fue suministrado por el cliente se evalúa como falso. Es decir, el cliente solicitó algo y proporcionó condiciones previas, sabiendo muy bien que esas condiciones previas podrían fallar. 412 nunca debería aparecer en el cliente de la nada, y no debería estar relacionado con la entidad de solicitud per se .


1
Debo señalar los RFC HTTP / 1.1 actualizados: 400 Bad Request, 409 Conflict, 403 Forbidden, etc. viven en tools.ietf.org/html/rfc7231 ; 412 La condición previa fallida está en tools.ietf.org/html/rfc7232#section-4.2
Matty K

41

Es divertido volver 418 I'm a teapota las solicitudes que obviamente están diseñadas o son maliciosas y que "no pueden suceder", como un error en la comprobación de CSRF o la falta de propiedades de solicitud.

2.3.2 418 Soy una tetera

Cualquier intento de preparar café con una tetera debe dar como resultado el código de error "418 Soy una tetera". El cuerpo de la entidad resultante PUEDE ser corto y robusto.

Para mantenerlo razonablemente serio, restrinjo el uso de códigos de error divertidos a puntos finales RESTful que no están expuestos directamente al usuario.


11
Impleméntelo de tal manera que su API regrese 418 I'm a teapotpara todas las solicitudes provenientes de su jefe :)
vikarjramun

2
@vikarjramun, he construido un RESTO ficticio e hice uno fuera de línea. (prelanzamiento) ahora nuestros estudiantes están buscando intentar crear solicitudes de datos válidas, pero todo es una tetera. Soy el "jefe", pero también está funcionando.
LenglBoy

2
Este RFC es tonto. Puede preparar café en una tetera, siempre que lo vierta a través de un colador de té en su taza. Es como usar té de hojas sueltas. También puedes preparar té en una cafetería sin problemas.
gburton

2
@gburton Sin embargo, eso requiere la intervención de un humano. A través de la red, definitivamente necesita un dispositivo con capacidad de café para hacer café. Por supuesto, una cafetera y tetera no debería responder con un 418.
Jasper
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.