400 vs 422 respuesta a publicación de datos

Para reflejar la situación a partir de 2015:

Los códigos de respuesta 400 y 422 serán tratados de la misma manera por los clientes y los intermediarios, por lo que en realidad no hace una diferencia concreta que utilice.

Sin embargo, yo esperaría ver 400 actualmente utilizado más ampliamente, y además las aclaraciones que el HTTPbis spec proporciona hacen que sea el más apropiado de los dos códigos de estado:

• La especificación HTTPbis aclara la intención de 400 para no ser únicamente para errores de sintaxis. La frase más amplia "indica que el servidor no puede o no procesará la solicitud debido a algo que se percibe como un error del cliente" ahora se usa.
• 422 Es específicamente una extensión WebDAV, y no se hace referencia en RFC 2616 o en la especificación HTTPbis más reciente.

Para el contexto, HTTPbis es una revisión de la especificación HTTP/1.1 que intenta aclarar áreas que no son claras o inconsistentes. Una vez que ha alcanzado estado aprobado reemplazará a RFC2616.

400 Bad Request es el código de estado HTTP adecuado para su caso de uso. El código está definido por HTTP/0.9-1.1 RFC.

La solicitud no pudo ser entendida por el servidor debido a malformaciones sintaxis. El cliente NO DEBE repetir la solicitud sin modificaciones.

Http://tools.ietf.org/html/rfc2616#section-10.4.1

422 La entidad no procesable está definida por RFC 4918 - WebDAV. Tenga en cuenta que hay una ligera diferencia en comparación con 400, véase el texto citado a continuación.

Esta condición de error puede ocurrir si un XML el cuerpo de la solicitud contiene bien formado (es decir, sintácticamente correcto), pero semánticamente erróneas, instrucciones XML.

Para mantener una interfaz uniforme, debe usar 422 solo en el caso de respuestas XML y también debe admitir todos los códigos de estado definidos por la extensión Webdav, no solo 422.

Http://tools.ietf.org/html/rfc4918#page-78

Véase también Marcos Nottingham publicar en los códigos de estado:

Es un error tratar de mapear cada parte de su aplicación "profundamente" en los códigos de estado HTTP; en la mayoría de los casos el nivel de granularidad querer estar apuntando es mucho más tosco. En caso de duda, está bien usar los códigos de estado genéricos 200 OK, 400 Solicitud incorrecta y 500 Internos Error de servicio cuando no hay un mejor ajuste .

Cómo Pensar en los Códigos de Estado HTTP

No hay una respuesta correcta, ya que depende de cuál sea la definición de "sintaxis" para su solicitud. Lo más importante es que usted:

1. Use el(los) código (s) de respuesta consistentemente
2. Incluya tanta información adicional en el cuerpo de respuesta como pueda para ayudar al desarrollador(es) que usa su API a averiguar qué está pasando.=

Antes de que todo el mundo salta sobre mí por decir que no hay una respuesta correcta o incorrecta aquí, permítanme explicar un poco acerca de cómo llegué a conclusion.

En este ejemplo específico, la pregunta del OP es sobre una solicitud JSON que contiene una clave diferente de la esperada. Ahora, el nombre de la clave recibida es muy similar, desde el punto de vista del lenguaje natural, a la clave esperada, pero es, estrictamente, diferente, y por lo tanto no (generalmente) reconocido por una máquina como equivalente.

Como dije anteriormente, el factor decisivo es lo que se entiende por sintaxis. Si la solicitud se envió con un tipo de contenido de application/json, entonces sí, el request es sintácticamente válido porque es una sintaxis JSON válida, pero no semánticamente válido, ya que no coincide con lo que se espera. (suponiendo una definición estricta de lo que hace que la solicitud en cuestión sea semánticamente válida o no).

Si, por otro lado, la solicitud se envió con un tipo de contenido personalizado más específico como application/vnd.mycorp.mydatatype+json que, tal vez, especifica exactamente qué campos se esperan, entonces diría que la solicitud podría ser fácilmente inválida sintácticamente, por lo tanto la respuesta de 400.

En el caso en cuestión, dado que la clave estaba equivocada, no el valor , había un error de sintaxis si había una especificación para qué son las claves válidas. Si no hubiera una especificación para las claves válidas, o el error era con un valor, entonces sería un error semántico.

En primer lugar esta es una muy buena pregunta.

400 Solicitud incorrecta: Cuando falta una información crítica en la solicitud

Por ejemplo, el encabezado authorization o el encabezado content type. Que es absolutamente requerido por el servidor para entender la solicitud. Esto puede diferir de un servidor a otro.

422 Entidad no procesable - Cuando el cuerpo de la solicitud no se puede analizar.

Esto es menos grave que 400. La solicitud ha llegado al servidor. El servidor ha reconocido la la petición tiene la estructura básica correcta. Pero la información en el cuerpo de la solicitud no se puede analizar o entender.

Por ejemplo, Content-Type: application/xml cuando el cuerpo de la solicitud es JSON.

Aquí hay un artículo que muestra los códigos de estado y su uso en las API REST. https://metamug.com/article/status-codes-for-rest-api.php

422 Entidad no procesable Explicada Actualizado: 6 de marzo de 2017

¿Qué Es 422 Entidad No Procesable?

Un código de estado 422 se produce cuando una solicitud está bien formada, sin embargo, debido para errores semánticos no se puede procesar. Este estado HTTP fue introducido en RFC 4918 y está más específicamente orientado hacia HTTP extensiones para Creación y Control de versiones Distribuidas en la Web (WebDAV).

Hay cierta controversia sobre si los desarrolladores o no debe devolver un error 400 vs 422 a los clientes (más sobre las diferencias entre ambos estados a continuación). Sin embargo, en la mayoría de los casos, se acuerda después de eso, el estado 422 solo debe devolverse si admite WebDAV capacidad.

Una definición palabra por palabra del código de estado 422 tomado de la sección 11.2 en RFC 4918 se puede leer a continuación.

El código de estado 422 (Entidad no procesable) significa el servidor entiende el tipo de contenido de la entidad de solicitud (por lo tanto, un 415 (Tipo de medio no compatible) El código de estado es inapropiado), y la sintaxis de la entidad request es correcta (por lo tanto un 400 (Bad Request) código de estado es inapropiado) pero no pudo procesar el contenido instrucción.

La definición continúa diciendo:

Por ejemplo, esta condición de error puede ocurrir si un cuerpo de solicitud XML contiene bien formado (es decir, sintácticamente correcto), pero semánticamente erróneas, instrucciones XML.

400 vs 422 Códigos de estado

Los errores de solicitud defectuosa hacen uso del código de estado 400 y deben ser devuelto al cliente si la sintaxis de la solicitud está mal formada, contiene enmarcado de mensaje de solicitud no válido, o tiene enrutamiento de solicitud engañoso. Este código de estado puede parecer bastante similar al 422 no procesable entidad, sin embargo, una pequeña pieza de información que los distingue es el hecho de que la sintaxis de una entidad de solicitud para un error 422 es correcto, mientras que la sintaxis de una solicitud que genera a 400 el error es incorrecto.

El uso del estatus 422 debe reservarse solo para muy particulares casos de uso. En la mayoría de los otros casos en los que se ha producido un error del cliente debido para la sintaxis malformada, se debe usar el estado de la solicitud 400 Bad.

Https://www.keycdn.com/support/422-unprocessable-entity /

Su caso: HTTP 400 es el código de estado correcto para su caso desde la perspectiva REST, ya que es sintácticamente incorrecto enviar sales_tax en lugar de tax, aunque es un JSON válido. Normalmente, la mayoría de los frameworks del lado del servidor aplican esto al asignar el JSON a objetos. Sin embargo, hay algunas implementaciones REST que ignoran new key en el objeto JSON. En ese caso, una especificación personalizada content-type para aceptar solo campos válidos puede ser forzada por el lado del servidor.

Ideal Escenario para 422:

En un mundo ideal, 422 es preferible y generalmente aceptable enviar como respuesta si el servidor entiende el tipo de contenido de la entidad de solicitud y la sintaxis de la entidad de solicitud es correcta, pero no pudo procesar los datos porque son semánticamente erróneos.

Situaciones de más de 400 422:

Recuerde, el código de respuesta 422 es un código de estado HTTP (WebDAV) extendido. Todavía hay algunos clientes HTTP / front-end bibliotecas que no están preparadas para manejar 422. Para ellos, es tan simple como "HTTP 422 está mal, porque no es HTTP". Desde la perspectiva del servicio, 400 no es muy específico.

En la arquitectura empresarial, los servicios se despliegan principalmente en capas de servicios como SOA, IDM, etc. Por lo general, sirven a varios clientes que van desde un cliente nativo muy antiguo hasta un cliente HTTP más reciente. Si uno de los clientes no maneja HTTP 422, las opciones son pedirle al cliente que actualice o cambie su código de respuesta a HTTP 400 para todos. En mi experiencia, esto es muy raro en estos días, pero sigue siendo una posibilidad. Por lo tanto, siempre se requiere un estudio cuidadoso de su arquitectura antes de decidir los códigos de respuesta HTTP.

Para manejar situaciones como estas, las capas de servicio normalmente usan versioning o setup configuration para que los clientes de estricta conformidad HTTP envíen 400, y envíen 422 para el resto de ellos. De esta manera proporcionan soporte de compatibilidad hacia atrás para los consumidores existentes, pero en al mismo tiempo proporcionar la capacidad para que los nuevos clientes consuman HTTP 422.

La última actualización de RFC7321 dice:

The 400 (Bad Request) status code indicates that the server cannot or
   will not process the request due to something that is perceived to be
   a client error (e.g., malformed request syntax, invalid request
   message framing, or deceptive request routing).

Esto confirma que los servidores pueden enviar HTTP 400 para solicitudes no válidas. 400 ya no se refiere solo al error de sintaxis, sin embargo, 422 sigue siendo una respuesta genuina siempre que los clientes puedan manejarlo.

Estudio de caso: GitHub API

Https://developer.github.com/v3/#client-errors

Tal vez copiar de APIs bien conocidas es una idea sabia:

Hay tres tipos posibles de errores de cliente en llamadas API que reciben cuerpos de solicitud:

El envío de JSON no válido dará lugar a una respuesta de 400 solicitudes incorrectas.

HTTP/1.1 400 Bad Request
Content-Length: 35

{"message":"Problems parsing JSON"}

El envío del tipo incorrecto de valores JSON dará lugar a una respuesta de 400 solicitudes incorrectas.

HTTP/1.1 400 Bad Request
Content-Length: 40

{"message":"Body should be a JSON object"}

Enviando los campos no válidos darán como resultado una respuesta de entidad 422 no procesable.

HTTP/1.1 422 Unprocessable Entity
Content-Length: 149

{
  "message": "Validation Failed",
  "errors": [
    {
      "resource": "Issue",
      "field": "title",
      "code": "missing_field"
    }
  ]
}

En realidad debe devolver "200 OK" y en el cuerpo de respuesta incluir un mensaje sobre lo que sucedió con los datos publicados. Entonces depende de tu aplicación entender el mensaje.

La cosa es que los códigos de estado HTTP son exactamente eso - códigos de estado HTTP. Y esos están destinados a tener significado solo en la capa de transporte, no en la capa de aplicación. La capa de aplicación realmente nunca debería saber que se está utilizando HTTP. Si cambiaste la capa de transporte de HTTP para las Palomas mensajeras, no debe afectar su capa de aplicación de ninguna manera.

Permítanme darles un ejemplo no virtual. Digamos que te enamoras de una chica y ella te quiere pero su familia se muda a un país completamente diferente. Te da su nueva dirección de correo. Naturalmente, usted decide enviarle una carta de amor. Así que a escribir la carta, la puso en un sobre, escribir su dirección en el sobre, puso un sello sobre él y enviarlo. Ahora consideremos estos escenarios

1. Olvidaste escribir un nombre de calle. Recibirá una carta sin abrir con un mensaje escrito en ella diciendo que la dirección está mal formada. Arruinaste la solicitud y la oficina de correos receptora no puede manejarla. Eso es el equivalente a recibir "400 Solicitudes erróneas".
2. Así que arreglas la dirección y envías la carta de nuevo. Pero por mala suerte escribiste mal el nombre de la calle. Usted recibirá la carta de nuevo con un mensaje diciendo, que la dirección no existe. Eso es el equivalente a recibir "404 No encontrado".
3. Arregla la dirección de nuevo y esta vez logra escribir la dirección correctamente. Tu chica recibe la carta y te responde. Es el equivalente a recibir "200 OK". Sin embargo, esto no significa que le guste lo que escribió en su carta. Simplemente significa que ella recibió su mensaje y tiene una respuesta para usted. Hasta que abras el sobre y leas su carta no puedes saber si ella te extraña mucho o quiere romper contigo.

En resumen: Devolver "200 OK" no significa que la aplicación del servidor tenga buenas noticias para usted. Solo significa que tiene algunas noticias.

PD: El código de estado 422 tiene un significado solo en el contexto de WebDAV. Si no está trabajando con WebDAV, entonces 422 tiene exactamente el mismo significado estándar que cualquier otro código no estándar = que es none.