O que significa o código de erro HTTP de 400 pedidos inválidos?

No caso de uma API de descanso com uma carga JSON, 400 são tipicamente, e corretamente eu diria, usados para indicar que o JSON é inválido de alguma forma de acordo com a especificação API para o serviço.

Imagine em vez disso que isto era XML em vez de JSON. Em em ambos os casos, o XML nunca passaria na validação do esquema -- seja por causa de um elemento indefinido ou de um valor de elemento impróprio. Seria um mau pedido. O mesmo negócio aqui.

De w3.org

10.4.1 400 Mau Pedido

O pedido não pôde ser entendido pelo servidor devido a malformações sintaxe. O cliente não deve repetir o pedido sem modificacao.

Seleccionar um código de resposta HTTP é uma tarefa bastante fácil e pode ser descrita por regras simples. A única parte complicada que é frequentemente esquecida é o parágrafo 6.5 da RFC 7231:

Excepto quando responde a um pedido principal, o servidor deve enviar um representação contendo uma explicação da situação de erro, e se é uma condição temporária ou permanente.

As regras são as seguintes:

1. Se o pedido foi bem sucedido, então devolve o código 2xx (3xx para redireccionar). Se houve um erro lógico interno em um servidor, então retorne 5xx. se houver algo errado no pedido do cliente, então retorne o código 4xx.
2. Veja o código de resposta disponível na categoria seleccionada. Se um deles tiver um nome que corresponda à sua situação, pode usá-lo. Caso contrário, apenas recuar para o código x00 (200, 400, 500). Se duvidarem, recuem para o código x00.
3. Devolve a descrição do erro no corpo de resposta. Para os códigos 4xx deve conter o suficiente informação para o desenvolvedor do cliente entender a razão e corrigir o cliente. Para 5xx por razões de segurança, nenhum detalhe deve ser revelado.
4. Se o cliente precisa de distinguir diferentes erros e ter uma reacção diferente dependendo dele, defina um formato de erro legível e extensível da máquina e use-o em toda a parte na sua API. É uma boa prática fazê-lo desde o início.
5. tenha em mente que o desenvolvedor do cliente pode fazer coisas estranhas e tentar processar strings que você retornar como descrição legível humana. E ao mudar as cordas, vai quebrar clientes tão mal escritos. Por isso, forneça sempre uma descrição legível por máquina e tente evitar a comunicação de informações adicionais no texto.

Então, no seu caso, eu tinha devolvido 400 erros e algo assim se "Roman" é obtido a partir da entrada do utilizador e o cliente deve ter uma reacção específica:

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

Ou um erro mais genérico, se tal situação for um erro de má lógica num cliente e não for esperado, a menos que o programador fez algo errado:

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

Em nenhum dos casos é a "sintaxe malformada". É a semântica que está errada. Assim, IMHO a 400 é inapropriado. Em vez disso, seria apropriado devolver um 200 junto com algum tipo de objeto de erro como { "error": { "message": "Unknown request keyword" } } ou o que quer que seja.

Considere o(s) Caminho (s) de processamento do cliente. Um erro na sintaxe (por exemplo, JSON inválido) é um erro na lógica do programa, em outras palavras, um bug de algum tipo, e deve ser tratado de acordo, de uma forma semelhante a um 403, dizer; em outras palavras, algo o mal correu mal.

Um erro num valor de parâmetro, por outro lado, é um erro de semântica, talvez devido à entrada mal validada do utilizador. Não é um erro HTTP (embora eu suponha que possa ser um 422). O caminho de processamento seria diferente.

Por exemplo, em jQuery, eu preferiria não ter que escrever um único manipulador de erros que lida com tanto coisas como 500 e algum erro semântico específico de app. Outros frameworks, Ember para um, também tratam erros HTTP como 400s e 500s identicamente como grandes falhas de gordura, exigindo que o programador para detectar o que está acontecendo e branch dependendo se é um erro "real" ou não.

Usar os códigos de Estado 400 para qualquer outra finalidade que não seja indicar que o pedido é malformado é simplesmente errado.

Se a carga útil do pedido contiver uma sequência de 'bytes' que não pôde ser processada como application/json (Se o servidor espera que esse dataformat), o código de estado apropriado é 415:

O servidor recusa-se a atender o pedido porque a entidade de o pedido está num formato não suportado pelo recurso solicitado para solicitar metodo.

Se a carga útil solicitada estiver sintaticamente correcta mas semanticamente incorrecta, pode ser utilizado o código de resposta não-normalizado 422, ou o código de estado padrão 403:

O servidor compreendeu o pedido, mas recusa-se a cumpri-lo. A autorização não ajudará e o pedido não deve ser repetido.

Primeiro verifique o URL que pode estar errado, se estiver correcto, então verifique o corpo do pedido que está a enviar, a possível causa é que o pedido que está a enviar está a faltar a sintaxe correcta.

Para elaborar, verifique se há caracteres especiais no texto do pedido. Se ele está (Especial char) sendo usado esta é a causa raiz deste erro.

Tente copiar o pedido e analisar cada dado de tags.