400 BAD solicitud de código de error HTTP significado?

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

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

[{requestedResource:"Roman"}] 

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

[{blah:"Roman"}]

Un 400 significa que la solicitud fue malformada. 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 útil JSON, los 400 son típicamente, y diría correctamente, que se utilizan para indicar que el JSON no es válido de alguna manera de acuerdo con la especificación API para el servicio.

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

Imagínese, en cambio, que fuera XML en lugar de JSON. En ambos casos, el XML nunca pasaría la validación del esquema, ya sea debido a un elemento indefinido o un valor de elemento incorrecto. Esa sería una mala solicitud. El mismo trato aquí.

De w3.org

10.4.1 400 Solicitud incorrecta

El servidor no pudo entender la solicitud debido a una sintaxis incorrecta. El cliente NO DEBE repetir la solicitud sin modificaciones.

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

Excepto cuando se responde a una solicitud HEAD, el servidor DEBE enviar una representación que contenga una explicación de la situación de error y si se trata de una condición temporal o permanente.

Las reglas son las siguientes:

1. Si la solicitud fue exitosa, 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. Mire 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 recurra al código x00 (200, 400, 500). Si tiene dudas, recurra al código x00.
3. Descripción del error de retorno en el cuerpo de la respuesta. Para los códigos 4xx debe contener suficiente información para que el desarrollador del cliente comprenda el motivo y arregle el cliente. Para 5xx por razones de seguridad, no se deben revelar detalles.
4. Si el cliente necesita distinguir diferentes errores y tener diferentes reacciones dependiendo de él, defina un formato de error legible por máquina y extensible y úselo en todas partes en 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 e intentar analizar las cadenas que devuelve como descripción legible por humanos. Y al cambiar las cadenas, romperá clientes tan mal escritos. Por lo tanto, siempre proporcione una descripción legible por máquina e intente evitar informar información adicional en el texto.

Entonces, en su caso, devolví un error 400 y algo como esto si se obtiene "Roman" 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 dicha situación es un error lógico incorrecto en un cliente y no se espera, a menos que el desarrollador haya hecho algo incorrecto:

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

En ninguno de los casos la "sintaxis está mal formada". Son las semánticas las que están equivocadas. Por lo tanto, en mi humilde opinión un 400 es inapropiado. En cambio, 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 salió 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 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 único controlador de errores que se ocupe de cosas como 500 y algún error semántico específico de la aplicación. Otros marcos, Ember para uno, también tratan los errores HTTP como los 400 y 500 de manera idéntica como grandes fallas gordas, lo que requiere que el programador detecte lo que está sucediendo y se ramifique dependiendo de si es un error "real" o no.

Usar 400códigos de estado para cualquier otro propósito que no sea indicar que la solicitud está mal formada es simplemente incorrecto.

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 no admitido por el recurso solicitado para el método solicitado.

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

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

Piensa en las expectativas.

Como aplicación cliente, espera saber si algo sale mal en el lado del servidor. Si el servidor necesita arrojar un error cuando blahfalta o el requestedResourcevalor es incorrecto, sería apropiado un error 400.

Como complemento, para aquellos que podrían tener el mismo problema que el mío, estoy usando $.ajaxpara publicar datos del formulario en el servidor y también recibí el 400error al principio.

Supongamos que tengo una variable de JavaScript,

var formData = {
    "name":"Gearon",
    "hobby":"Be different"
    }; 

No use la variable formDatadirectamente como el valor de la clave datacomo a continuación:

$.ajax({
    type: "post",
    dataType: "json",
    url: "http://localhost/user/add",
    contentType: "application/json",
    data: formData,
    success: function(data, textStatus){
        alert("Data: " + data + "\nStatus: " + status); 
    }
});

En su lugar, use JSON.stringify para encapsular lo formDatasiguiente:

$.ajax({
    type: "post",
    dataType: "json",
    url: "http://localhost/user/add",
    contentType: "application/json",
    data: JSON.stringify(formData),
    success: function(data, textStatus){
        alert("Data: " + data + "\nStatus: " + status); 
    }
});

De todos modos, como otros han ilustrado, el error se debe a que el servidor no pudo reconocer que la solicitud causaba una sintaxis incorrecta, solo estoy planteando una instancia en la práctica. Espero que sea útil para alguien.

Primero verifique la URL, puede estar equivocada, si es correcta, luego verifique el cuerpo de la solicitud que está enviando, la posible causa es que la solicitud que está enviando no tiene la sintaxis correcta.

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

intente copiar la solicitud y analice todos y cada uno de los datos de etiquetas.