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

¿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.

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.

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.

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 .

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.