Os status codes HTTP são agrupados em cinco classes pelo seu primeiro dígito, e escolher o certo permite que os clients reajam corretamente sem fazer parse do body.
2xx Success — o request funcionou
3xx Redirection — ação adicional / recurso movido
4xx Client error — quem chamou fez algo errado
5xx Server error — o server falhou
2xx
200 OK — sucesso geral (GET, PUT, PATCH).201 Created — um recurso foi criado (retorne um header Location).202 Accepted — aceito para processamento assíncrono, ainda não concluído.204 No Content — sucesso sem body (comum para DELETE).4xx
400 Bad Request — sintaxe malformada ou input inválido.401 Unauthorized — não autenticado (credenciais ausentes/inválidas).403 Forbidden — autenticado mas sem permissão.404 Not Found — o recurso não existe.409 Conflict — conflita com o estado atual (ex. email duplicado).422 Unprocessable Entity — bem formado mas falha na validação.429 Too Many Requests — rate limited (limite de taxa excedido).5xx
500 Internal Server Error — uma falha inesperada do server.503 Service Unavailable — temporariamente fora do ar/sobrecarregado.POST /users → 201 Created
Location: /users/42
DELETE /users/42 → 204 No Content
GET /users/999 → 404 Not Found
{ "error": "user not found" }
A distinção-chave que os entrevistadores sondam: 401 ("quem é você?") vs 403 ("eu sei quem você é, mas não"), e 400 (sintaxe ruim) vs 422 (sintaxe válida, dados inválidos).
Os status codes são o sinal primário em uma response REST — clients, proxies, monitoramento, e a lógica de retry todos se baseiam neles, então acertá-los é essencial para a interoperabilidade. Uma falha comum é retornar 200 OK com um body { "error": ... }: isso força todo client a fazer parse do body para saber se a chamada teve sucesso, quebra o tooling HTTP genérico, e esconde falhas do monitoramento. Códigos precisos também guiam comportamento automático: um 429 ou 503 diz a um client bem construído para recuar e refazer (retry), enquanto um 4xx diz "não refaça, conserte o request". Os entrevistadores usam esta pergunta para checar se você entende HTTP como um contrato em vez de um transporte burro, e se você distingue corretamente os pares sutis (401/403, 400/422) — a marca de quem já construiu e consumiu APIs reais.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar