Código de status HTTP

Um código de status HTTP é a resposta curta do servidor a uma requisição. O primeiro dígito indica a classe: 1xx informativa, 2xx sucesso, 3xx redirecionamento, 4xx erro do cliente (a requisição estava errada) e 5xx erro do servidor (a requisição pode até estar correta, mas o servidor falhou). Fazer a asserção do código de status exato costuma ser a primeira verificação de qualquer teste de API.

Os códigos que testers mais usam

Código	Significado	Uso típico
200 OK	Sucesso com corpo	GET, ou uma atualização que retorna o recurso
201 Created	Um recurso foi criado	POST, com header Location
204 No Content	Sucesso, sem corpo	DELETE, alguns PUTs
301 / 302 / 304	Movido, encontrado em outro lugar, não modificado	Redirecionamentos e cache
400 Bad Request	Requisição malformada ou inválida	JSON quebrado, tipos errados
401 Unauthorized	Não autenticado	Token ausente, expirado ou inválido
403 Forbidden	Autenticado, mas sem permissão	Usuário válido, papel errado
404 Not Found	Recurso inexistente	Id desconhecido, ou ocultando um recurso proibido
409 Conflict	Conflita com o estado atual	E-mail duplicado, conflito de versão
422 Unprocessable Content	Bem formada, mas falha na validação	Violações de regras de negócio
429 Too Many Requests	Rate limit excedido	Muitas vezes com Retry-After
500 / 502 / 503 / 504	Erro do servidor, bad gateway, indisponível, timeout do gateway	Bugs e infraestrutura

401 versus 403

Apesar do nome, 401 Unauthorized trata de autenticação: o servidor não sabe quem você é. A solução é fazer login ou enviar um token válido, e a resposta deve incluir um header WWW-Authenticate. 403 Forbidden trata de autorização: o servidor sabe quem você é, e você não tem permissão para fazer aquilo. Fazer login de novo não vai ajudar. Uma suíte de testes deve cobrir os dois casos: sem token, com token expirado e com um token válido de um usuário sem a permissão necessária.

Erros comuns

• Verificar só o 200. A maioria dos defeitos está nos caminhos de erro. Uma entrada inválida deve receber um 4xx; um 500 significa entrada não tratada e merece um bug report.
• Erros com status 200. Uma mensagem de erro em um corpo 200 quebra os clientes e o monitoramento.
• Convenções inconsistentes. Algumas APIs usam 400 para toda entrada inválida, outras reservam 422 para falhas de validação. Qualquer uma serve; o bug é misturar as duas na mesma API.