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

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

  1. Datos inválidos pasados ​​mientras el usuario se registra como el formato de correo electrónico incorrecto
  2. El nombre de usuario / correo electrónico ya existe

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

Wikipedia:

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

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

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

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

403 – Prohibido se usa cuando el servidor desea evitar el acceso a un recurso.

La única otra opción que es 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 los navegadores deberían tratarlo igual que cualquier otro código de estado 4xx.

De RFC 4918 :

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 syntax de la entidad de solicitud es correcta (por lo tanto, 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 / el cuerpo de la solicitud), la respuesta adecuada 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 está distorsionada (como un mal formato de correo electrónico) use 400; pero si simplemente no tiene sentido (como @example.com ) usa 422.

Si el problema es que, como se indicó 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, “elegir un nombre de usuario / correo electrónico diferente). Sin embargo, en la especificación, 403 Forbidden [ 3 ] también se puede utilizar en este caso, a pesar de los argumentos sobre la Autorización HTTP.

412 Condición previa fallida [ 4 ] se usa cuando un encabezado de solicitud de condición previa (por ejemplo, If-Match ) proporcionado por el cliente se evalúa como falso. Es decir, el cliente solicitó algo y le dio 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 relacionarse con la entidad de solicitud per se .

Es divertido devolver 418 I'm a teapot para las solicitudes que son obviamente elaboradas o maliciosas y que “no pueden suceder”, como fallar el control CSRF o las propiedades de solicitud faltantes.

2.3.2 418 Soy una tetera

Cualquier bash de preparar café con una tetera debería dar como resultado el código de error “418 Soy una tetera”. El cuerpo de la entidad resultante PUEDE ser corto y fuerte.

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