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

verbos http laravel

Question

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

1. Los datos no válidos se pasaron mientras el usuario se registra como formato de correo electrónico incorrecto
2. El nombre de usuario / correo electrónico ya existe

Elegí el 403. También encontré que a continuación siento que se puede usar.

Wikipedia:

412 Error de condición previa: el servidor no cumple uno de los requisitos previos que el solicitante puso en la solicitud

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

Answer 1

400 es la mejor opción en ambos casos. Si desea aclarar más el error, puede cambiar la frase de motivo 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 la última modificación y los ETags.

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

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

Answer 2

Es divertido devolver 418 I''m a teapot para solicitudes que obviamente son malintencionadas o malintencionadas y "no puede suceder", como la comprobación de CSRF en caso de error o la falta de propiedades de solicitud.

2.3.2 418 soy una tetera

Cualquier intento de preparar café con una tetera debe dar lugar al 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 graciosos a puntos finales RESTful que no están directamente expuestos al usuario.

Answer 3

Recomendaría 422. No es parte de la especificación principal de HTTP, pero está definida por un estándar público (WebDAV) y debe ser tratada por los navegadores 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 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.

Answer 4

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

La RFC 4918 establece que 422 Entidad no procesable es aplicable cuando la entidad de solicitud está sintácticamente bien formada, pero es semánticamente errónea. Por lo tanto, si la entidad de la solicitud está distorsionada (como un formato de correo electrónico incorrecto), utilice 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, podría usar 409 Conflicto [ 2 ] con una descripción del conflicto y una pista sobre cómo solucionarlo (en este caso, "elija un diferente nombre de usuario / correo electrónico "). Sin embargo, en la especificación tal como está escrita, 403 Forbidden [ 3 ] también se puede usar 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 condición previa (por ejemplo, If-Match ) que fue proporcionado por el cliente se evalúa como falso. Es decir, el cliente solicitó algo y proporcionó condiciones previas, sabiendo muy bien que esas condiciones pueden fallar. 412 nunca se debe lanzar al cliente de la nada, y no debe relacionarse con la entidad de solicitud per se .