servicio - HTTP 400(solicitud incorrecta) para error lógico, sintaxis de solicitud mal formada
error 400 bad request wordpress (6)
La especificación HTTP / 1.1 (RFC 2616) tiene lo siguiente para decir sobre el significado del código de estado 400, Solicitud incorrecta (§10.4.1) :
La solicitud no pudo ser entendida por el servidor debido a una sintaxis mal formada. El cliente NO DEBE repetir la solicitud sin modificaciones.
Parece que en la actualidad existe una práctica general entre algunas API basadas en HTTP para usar 400 para indicar un error lógico en lugar de un error de sintaxis con una solicitud. Creo que las API hacen esto para distinguir entre 400 (inducido por el cliente) y 500 (inducido por el servidor). ¿Es aceptable o incorrecto usar 400 para indicar errores no sintácticos? Si es aceptable, ¿hay alguna referencia anotada en RFC 2616 que brinde más información sobre el uso previsto de 400?
Ejemplos:
A partir de este momento, el último borrador de la especificación HTTPbis , que pretende reemplazar y hacer que RFC 2616 sea obsoleto, states :
El código de estado 400 (Solicitud incorrecta) indica que el servidor no puede o no procesará la solicitud porque la sintaxis recibida no es válida, no tiene sentido o supera alguna limitación sobre lo que el servidor está dispuesto a procesar.
Esta definición, aunque por supuesto está sujeta a cambios, ratifica la práctica ampliamente utilizada de responder a los errores lógicos con un 400.
Aunque he estado usando 400 para representar errores lógicos también, debo decir que devolver 400 está mal en este caso debido a la forma en que lee la especificación. He aquí por qué creo que sí, el error lógico podría ser que una relación con otra entidad estaba fallando o no está satisfecha y hacer cambios en la otra entidad podría hacer que la misma última pase más tarde. Como intentar (completamente hipotético) agregar un empleado como miembro de un departamento cuando ese empleado no existe (error lógico). Agregar empleado como solicitud de miembro podría fallar porque el empleado no existe. Pero la misma solicitud exacta podría pasar después de que el empleado se haya agregado al sistema.
Solo mis 2 centavos ... Necesitamos abogados y jueces para interpretar el lenguaje en el RFC en estos días :)
Gracias, Vish
El estado 422 ( RFC 4918, sección 11.2 ) me viene a la mente:
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 sintaxis 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.
En los servidores Java EE se devuelve 400 si su URL se refiere a una "aplicación web" inexistente. ¿Es eso un "error de sintaxis"? Depende de lo que quiere decir con un error de sintaxis. Yo diría que sí.
En inglés, las reglas de sintaxis prescriben ciertas relaciones entre las partes del discurso. Por ejemplo, "Bob se casa con María" es sintácticamente correcto, porque sigue el patrón {Noun + Verb + Sustantivo}. Mientras que "Bob marriage Mary" sería sintácticamente incorrecto, {Noun + Noun + Noun}.
La sintaxis de una URL simple es {protocolo +: + // + servidor +: + puerto}. De acuerdo con esto, " http://www.google.com:80 " es sintácticamente correcto.
¿Pero qué hay de "abc: //www.google.com: 80"? Parece seguir el mismo patrón exacto. Pero realmente es un error de sintaxis. ¿Por qué? Porque ''abc'' no es un protocolo DEFINIDO.
El punto es que determinar si tenemos o no una situación de 400 requiere más que analizar los caracteres, espacios y delimitadores. También debe reconocer cuáles son las "partes del discurso" válidas.
HTTPbis abordará el fraseo de 400 Bad Request para que cubra también los errores lógicos. Entonces 400 incorporarán 422.
De https://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-18#section-7.4.1
"El servidor no puede o no procesará la solicitud, debido a un error del cliente (por ejemplo, una sintaxis mal formada)"
Podría argumentarse que tener datos incorrectos en su solicitud es un error de sintaxis, incluso si su solicitud real en el nivel HTTP (línea de solicitud, encabezados, etc.) es sintácticamente válida.
Por ejemplo, si se documenta que un servicio web de Restful acepta POST con un tipo de application/vnd.example.com.widget+xml de contenido XML personalizado application/vnd.example.com.widget+xml , y en su lugar envía algún texto sin formato o un archivo binario, parece razonable tratarlo que como un error de sintaxis, su cuerpo de solicitud no está en la forma esperada.
Sin embargo, no conozco ninguna referencia oficial que respalde esto, ya que como siempre, parece que se debe a la interpretación de RFC 2616.
Actualización: tenga en cuenta la redacción revisada en RFC 7231 §6.5.1 :
El código de estado 400 (Solicitud incorrecta) indica que el servidor no puede o no procesará la solicitud debido a algo que se percibe como un error del cliente, por ejemplo, una sintaxis de solicitud mal formada, un marco de mensaje de solicitud no válido o un enrutamiento de solicitud engañoso.
parece apoyar este argumento más que el ahora obsoleto RFC 2616 §10.4.1 que decía simplemente:
La solicitud no pudo ser entendida por el servidor debido a una sintaxis mal formada. El cliente NO DEBE repetir la solicitud sin modificaciones.