HTTP methods declaram sua intenção sobre um recurso; status codes são a resposta codificada do servidor. Duas propriedades importam para os methods: safe (somente-leitura, sem efeitos colaterais) e idempotent (repeti-lo produz o mesmo resultado — importante para retries seguros).
| Method | Propósito | Safe | Idempotent |
|---|
| GET | Ler um recurso | Yes | Yes |
| POST | Criar / disparar uma ação | No | No |
| PUT | Substituir um recurso | No | Yes |
| PATCH | Atualizar parcialmente | No | No* |
| DELETE | Remover um recurso | No | Yes |
| HEAD | Como GET, só headers | Yes | Yes |
A distinção de idempotência é prática: como PUT e DELETE são idempotentes, um cliente pode fazer retry deles com segurança após um timeout; refazer um POST não idempotente arrisca criar uma duplicata (um clássico bug de cobrança dupla).
Status codes são agrupados pelo primeiro dígito:
1xx Informational request received, continuing (100 Continue, 101 Switching)
2xx Success it worked (200 OK, 201 Created, 204 No Content)
3xx Redirection go elsewhere (301 Moved, 304 Not Modified)
4xx Client error YOUR request is wrong (400, 401, 403, 404, 429)
5xx Server error the SERVER failed (500, 502, 503, 504)
A linha mais importante é a divisão 4xx vs 5xx: 4xx significa que o cliente enviou algo errado (input ruim, não autenticado, não encontrado) — refazer sem mudar nada não ajuda; 5xx significa que o servidor falhou — refazer (com backoff) pode ter sucesso. Conheça os do dia a dia de cor: 401 (não autenticado) vs 403 (autenticado mas não autorizado), 404 (não encontrado), 429 (rate limited), 500 (crash genérico do servidor), 502/503/504 (bad gateway / indisponível / gateway timeout — geralmente um problema de upstream ou sobrecarga).
Esses códigos são o contrato compartilhado entre todo cliente e servidor, então fluência aqui é esperada de qualquer um que constrói ou consome APIs. Os entrevistadores sondam as distinções que revelam entendimento real: 401 vs 403, PUT vs PATCH, e especialmente idempotência, que governa diretamente se os retries são seguros — uma preocupação central em sistemas distribuídos e fluxos de pagamento. Retornar o status code correto também torna sua API previsível e corretamente tratada por caches, proxies e bibliotecas de cliente, então esse conhecimento molda um bom design de API, não é apenas trivia.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar