rest - para - 400 BAD solicitud de código de error HTTP significado?

http/1.1 200 ok

Question

Tengo una solicitud JSON que estoy publicando en una URL HTTP.

¿Debería tratarse esto como 400 donde existe el campo requestResource pero "Roman" es un valor válido para este campo?

[{requestedResource:"Roman"}] 

¿Debería tratarse esto como 400 donde el campo "blah" no existe en absoluto?

[{blah:"Roman"}]

Answer 1

De w3.org

10.4.1 400 mala solicitud

El servidor no pudo comprender la solicitud debido a una sintaxis mal formada. El cliente NO DEBE repetir la solicitud sin modificaciones.

Answer 2

El uso de 400 códigos de estado para cualquier otro propósito que indicar que la solicitud tiene un formato incorrecto es simplemente erróneo.

Si la carga útil de la solicitud contiene una secuencia de bytes que no se pudo analizar como application/json (si el servidor espera ese formato de datos), el código de estado apropiado es 415 :

El servidor se niega a atender la solicitud porque la entidad de la solicitud está en un formato que el recurso solicitado no admite para el método solicitado.

Si la carga útil de la solicitud es sintácticamente correcta pero semánticamente incorrecta, se puede usar el código de respuesta 422 no estándar, o el código de estado 403 estándar:

El servidor entendió la solicitud, pero se niega a cumplirla. La autorización no ayudará y la solicitud NO DEBE repetirse.

Answer 3

En ninguno de los dos casos la "sintaxis está mal formada". Es la semántica que está mal. Por lo tanto, IMHO a 400 es inapropiado. En su lugar, sería apropiado devolver un 200 junto con algún tipo de objeto de error como { "error": { "message": "Unknown request keyword" } } o lo que sea.

Considere las rutas de procesamiento del cliente. Un error en la sintaxis (por ejemplo, JSON no válido) es un error en la lógica del programa, en otras palabras, un error de algún tipo, y debe manejarse en consecuencia, de manera similar a un 403, por ejemplo; en otras palabras, algo malo ha salido mal.

Un error en un valor de parámetro, por otro lado, es un error de semántica, tal vez debido a una entrada de usuario mal validada. No es un error de HTTP (aunque supongo que podría ser un 422). La ruta de procesamiento sería diferente.

Por ejemplo, en jQuery, preferiría no tener que escribir un solo controlador de errores que se ocupe tanto de 500 como de algunos errores semánticos específicos de la aplicación. Otros marcos, Ember for one, también tratan los errores HTTP como 400 y 500 como fallas grandes y graves, lo que requiere que el programador detecte lo que está pasando y se ramifique dependiendo de si se trata de un error "real" o no.

Answer 4

Piense en las expectativas.

Como una aplicación cliente, espera saber si algo sale mal en el lado del servidor. Si el servidor necesita lanzar un error cuando falta blah o el valor de requiredResource es incorrecto, sería apropiado un error 400.

Answer 5

Primero verifique la URL que podría estar equivocada, si es correcta, luego verifique el cuerpo de la solicitud que está enviando, la causa posible es que la solicitud que está enviando carece de sintaxis correcta.

Para elaborar, compruebe si hay caracteres especiales en la cadena de solicitud. Si se está utilizando (carácter especial) esta es la causa raíz de este error.

intente copiar la solicitud y analizar todos los datos de las etiquetas.

Answer 6

Seleccionar un código de respuesta HTTP es una tarea bastante fácil y puede describirse con reglas simples. La única parte difícil que a menudo se olvida es el párrafo 6.5 de RFC 7231:

Excepto al responder a una solicitud HEAD, el servidor DEBE enviar una representación que contenga una explicación de la situación de error y si es una condición temporal o permanente.

Las reglas son las siguientes:

1. Si la solicitud fue exitosa, entonces devuelva el código 2xx (3xx para la redirección). Si hubo un error lógico interno en un servidor, devuelva 5xx. Si hay algo incorrecto en la solicitud del cliente, devuelva el código 4xx.
2. Busque en el código de respuesta disponible de la categoría seleccionada. Si uno de ellos tiene un nombre que coincida bien con su situación, puede usarlo. De lo contrario, simplemente retroceda al código x00 (200, 400, 500). Si dudas, retrocede al código x00.
3. Devuelve la descripción del error en el cuerpo de la respuesta. Para los códigos 4xx, debe contener suficiente información para que el desarrollador del cliente entienda la razón y arregle al cliente. Por 5xx por razones de seguridad, no se deben revelar detalles.
4. Si el cliente necesita distinguir diferentes errores y tener diferentes reacciones dependiendo de ellos, defina un formato de error legible y extensible por máquina y utilícelo en cualquier parte de su API. Es una buena práctica hacer eso desde el principio.
5. Tenga en cuenta que el desarrollador del cliente puede hacer cosas extrañas y tratar de analizar cadenas que usted devuelve como una descripción legible. Y al cambiar las cadenas, romperás clientes tan mal escritos. Por lo tanto, siempre proporcione una descripción legible por la máquina y evite reportar información adicional en el texto.

Entonces, en su caso, devolví 400 errores y algo como esto si "Roman" se obtiene de la entrada del usuario y el cliente debe tener una reacción específica:

{
    "error_type" : "unsupported_resource",
    "error_description" : "/"Roman/" is not supported"
}

o un error más genérico, si tal situación es un error lógico erróneo en un cliente y no se espera, a menos que el desarrollador haya cometido un error:

{
    "error_type" : "malformed_json",
    "error_description" : "/"Roman/" is not supported for /"requestedResource/" field"
}

Answer 7

Un 400 significa que la solicitud estaba mal formada. En otras palabras, el flujo de datos enviado por el cliente al servidor no siguió las reglas.

En el caso de una API REST con una carga de JSON, los 400 se suelen utilizar, y diría correctamente, para indicar que el JSON no es válido de alguna manera según la especificación de la API para el servicio.

Según esa lógica, los dos escenarios que proporcionaste deben ser de 400.

Imagínate, en cambio, esto era XML en lugar de JSON. En ambos casos, el XML nunca pasaría la validación del esquema, ya sea debido a un elemento no definido o un valor de elemento inadecuado. Eso sería una mala petición. La misma oferta aquí.