ANÚNCIO

~/questoes/programacao

Qual status code HTTP deve ser retornado ao erro de validação?

Responda, confira o feedback e use o resultado para orientar sua revisão.
Para fixar

HTTP Status Codes: Validação de Dados em APIs

Conceito central

Status codes HTTP são números que indicam o resultado de uma requisição feita a um servidor. Ao construir uma API, você precisa retornar o código correto para cada situação, especialmente quando os dados enviados pelo cliente estão inválidos ou incompletos.

Por que essa resposta faz sentido

O status 400 Bad Request é o código apropriado quando o cliente envia dados inválidos ou malformados para a API. Ele comunica claramente que o problema está na requisição do cliente, não no servidor, permitindo que o consumidor da API saiba exatamente o que corrigir.

Armadilhas comuns

  • Confundir 400 (cliente enviou dados ruins) com 500 (servidor teve problema interno)
  • Usar 200 OK em respostas de erro por parecer 'mais simples', ignorando convenções HTTP
  • Não diferenciar entre erros de validação (400) e servidor indisponível (503)

Entenda as alternativas

A

O 500 Internal Server Error indica problema no servidor, não na validação dos dados enviados. Usar 500 para validação confundiria o cliente, fazendo-o achar que o servidor está quebrado quando na verdade ele enviou dados errados.

B

O 200 OK significa que a requisição foi bem-sucedida. Retornar 200 quando há erros de validação é enganoso e viola as convenções HTTP, deixando o cliente sem saber que algo deu errado.

C

O 503 Service Unavailable é usado quando o servidor está temporariamente indisponível ou sobrecarregado, não para problemas de validação de dados. Este código não se aplica à situação descrita.

D

O 400 Bad Request é o status correto para dados inválidos. Ele sinaliza que o cliente deve revisar e corrigir os dados antes de reenviar a requisição, seguindo o padrão HTTP recomendado.

Dica prática: Ao desenvolver uma API com Laravel 12, use Form Requests para validar dados automaticamente. O framework retorna 422 (Unprocessable Entity) por padrão, que é ainda mais específico que 400. Ambos comunicam erro de validação, mas 422 é ainda mais claro sobre a causa.

Revise pensando: Se um usuário enviar um email inválido para seu formulário de cadastro em uma API, qual status code você retornaria e por quê?