O que é o código de status HTTP 400 e por que ele aparece no seu dia a dia
O código 400 de status HTTP é uma resposta do servidor indicando que a requisição enviada por um cliente contém dados malformados ou inválidos. O nome oficial é Bad Request. Nada dramático. É simplesmente o servidor dizendo que não conseguiu entender o que você mandou porque alguma coisa estava errada nos parâmetros, no formato ou nos cabeçalhos.
como que se escreve 400 em um contexto técnico
Na prática, quando você vê "400" aparecendo em logs, no console do navegador ou em mensagens de erro de uma API, está lidando com uma requisição que o servidor rejeitou na porta de entrada. Não é um erro do servidor em si. É um erro de quem enviou a requisição. A diferença é importante porque muda completamente a forma como você deve investigar o problema. Eu já perdi horas rastreando um bug onde o cliente achava que o servidor estava com defeito, quando na realidade o problema estava em um campo JSON sendo enviado sem a codificação correta de acentos. O servidor devolvia 400 sem muita explicação, e a mensagem de erro era algo genérico como "invalid input". Só vi o que estava acontecendo quando passei a logar o corpo bruto de cada requisição antes de ser processado.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O cenário mais comum é uma API REST que espera um payload específico e recebe algo diferente. Pode ser um campo numérico vindo como string, um campo obrigatório faltando, um token de autorização malformed, ou até um cabeçalho Content-Type errado. O servidor valida tudo isso antes de deixar a requisição entrar no sistema e rejeita logo na frente se algo não bater. O que a maioria dos desenvolvedores não considera na hora de debugar um 400 é que o erro pode estar em algo aparentemente irrelevante. Um espaço em branco extra no início de um token, uma vírgula a mais no final de um array serializado, um campo que deveria ser null mas foi omitido completamente em vez de declarado como nulo. Diferentes frameworks de backend tratam isso de formas diferentes. Alguns são rigorosos e rejeitam tudo. Outros são mais flexíveis e ignoram pequenas divergências.
Um caso que me marcou foi quando um cliente enviava datas no formato americano MM/DD/YYYY para uma API que esperava ISO 8601 YYYY-MM-DD. O servidor convertia tudo com um parser rígido e simplesmente devolvia 400 sem especificar qual campo estava errado. A solução foi adicionar um middleware de validação de entrada que retorna mensagens de erro detalhadas por campo, ao invés de um 400 genérico. Isso reduziu o tempo médio de resolução de problemas de formato de duas horas para cerca de quinze minutos. Outra armadilha comum é a limitação de tamanho do corpo da requisição. Muitos servidores têm um limite configurado para o tamanho máximo do payload, e se você enviar um arquivo grande ou um JSON muito extenso, a resposta pode ser um 400 disfarçado de erro de bad request, quando na verdade o problema é o tamanho. O nginx, por exemplo, tem a diretiva client_max_body_size que, se não estiver configurada corretamente, causa esse comportamento confuso. A correção é ajustar o valor no arquivo de configuração do proxy reverso antes de qualquer coisa.
Quando você está construindo uma API, o recomendado é nunca devolver um 400 sem uma mensagem clara no corpo da resposta indicando exatamente o que está errado. Um status 400 bem formatado com detalhes dos campos problemáticos economiza tempo tanto para quem consome a API quanto para quem dá suporte. A falta dessa informação é provavelmente a maior causa de frustração com esse código de status no dia a dia. Se você precisa validar dados de entrada de forma consistente, uma abordagem pragmática é usar bibliotecas de validação como Joi para Node.js, Pydantic para Python, ou Bean Validation para Java. Elas permitem definir esquemas claros, gerar mensagens de erro customizadas por campo e ainda centralizam a lógica de validação em um só lugar, o que facilita a manutenção quando os requisitos mudam.
