Método, código de status e cabeçalhos são três dos sinais mais úteis em requisições e respostas HTTP. QA frequentemente consegue entender boa parte de um problema antes de ler o corpo, examinando apenas esses três elementos.
Iniciantes geralmente focam nos dados da resposta: se chegou JSON e se um campo está presente ou ausente. Isso importa, mas primeiro é preciso entender algo mais fundamental: o que o cliente pretendia fazer, como o servidor interpretou isso e qual contexto técnico acompanhava a requisição. Método, código de status e cabeçalhos fornecem essas informações.
Aprender a interpretá-los com confiança torna a investigação de defeitos muito mais rápida.
Método
O método HTTP expressa a intenção do cliente: o que ele tentava fazer, e não o resultado.
- →GET — consultar dados.
- →POST — criar uma entidade ou acionar uma ação.
- →PUT — substituir um recurso completamente.
- →PATCH — atualizar parte de um recurso.
- →DELETE — excluir um recurso ou marcá-lo como inativo.
Na prática, as equipes nem sempre usam os métodos perfeitamente, e você deve considerar isso. Mesmo assim, QA precisa entender seu significado. Se um cliente envia GET e os dados mudam como resultado, isso merece atenção. Criar uma entidade por GET viola convenções da API e expectativas de cache, repetibilidade e segurança.
Outro conceito importante é a idempotência. Alguns métodos podem ser repetidos sem alterar o resultado pretendido; outros não. Isso importa em novas tentativas, cliques repetidos, redes instáveis e testes automatizados. Enviar a mesma requisição duas vezes acidentalmente pode ter consequências diferentes para POST e PUT, e suas verificações precisam considerar isso.
Código de status
Um código de status é um resumo técnico breve de como uma requisição foi processada. Ele não explica tudo, mas identifica imediatamente a categoria do resultado.
- →1xx — informação técnica intermediária.
- →2xx — a requisição foi processada com sucesso.
- →3xx — é necessário um redirecionamento ou uma etapa adicional.
- →4xx — um problema na requisição, nos dados ou no acesso do cliente.
- →5xx — um erro do lado do servidor.
Essas categorias bastam para QA ter uma noção inicial da situação. Um testador experiente vai além e entende os códigos individuais mais comuns.
- →200 OK — a requisição foi bem-sucedida.
- →201 Created — uma entidade foi criada.
- →204 No Content — a operação foi bem-sucedida, sem corpo na resposta.
- →301 / 302 / 307 / 308 — redirecionamentos.
- →400 Bad Request — o servidor não aceita a requisição na forma atual.
- →401 Unauthorized — o cliente não está devidamente autenticado.
- →403 Forbidden — o cliente é reconhecido, mas não tem acesso.
- →404 Not Found — o recurso não foi encontrado.
- →409 Conflict — um conflito de estado.
- →422 Unprocessable Content — a estrutura da requisição é válida, mas seu significado de negócio ou seus dados falham na validação.
- →500 Internal Server Error — um erro interno do servidor.
- →502, 503, 504 — problemas entre serviços, de sobrecarga ou de disponibilidade.
O objetivo é entender como os códigos ajudam a isolar problemas, em vez de decorar toda a tabela.
Por exemplo, 401 e 403 significam coisas diferentes. Um 404 pode significar tanto “esta URL não existe” quanto “esta entidade não existe”. Um 200 não garante lógica de negócio correta. Um 500 não identifica o ponto exato da falha, mas mostra rapidamente que o problema vai além do formulário no frontend.
Por que 200 OK garante pouco sozinho
Uma das armadilhas mais comuns é presumir que, se uma API retorna 200, está tudo certo.
- →Retornar dados incorretos.
- →Retornar uma lista vazia quando se esperava um objeto.
- →Esconder um erro de negócio em um campo error.
- →Executar uma operação apenas parcialmente.
- →Retornar dados desatualizados do cache.
Assim, QA sempre interpreta o código de status junto com o corpo da resposta e o contexto do cenário. Sucesso técnico não significa necessariamente que o comportamento do produto esteja correto.
Cabeçalhos
Cabeçalhos fornecem contexto adicional à requisição e à resposta. Muitas vezes parecem secundários até você investigar problemas reais.
- →Tipo de dados (Content-Type).
- →Formato de resposta esperado (Accept).
- →Autorização (Authorization).
- →Cookies.
- →Idioma ou localidade.
- →Cache (Cache-Control, ETag, If-None-Match).
- →Identificadores de correlação.
- →Políticas de CORS.
- →Políticas de segurança.
Cabeçalhos são especialmente importantes para QA porque frequentemente explicam bugs aparentemente “estranhos”.
- →O backend espera application/json, mas o cliente envia outro Content-Type.
- →Existe um token, mas ele foi enviado no cabeçalho errado.
- →Um cookie não chegou ou não foi salvo.
- →O cache retornou uma versão antiga dos dados.
- →O navegador bloqueou uma requisição por causa de CORS.
- →Um proxy reverso reescreveu alguns cabeçalhos.
- →A requisição especifica uma localidade, mas a resposta usa outra.
Cabeçalhos são uma parte substancial do protocolo: carregam contexto essencial. Sem ele, uma requisição pode ser tecnicamente válida, mas logicamente incorreta.
Como isso ajuda QA na prática
Considere um bug: o usuário não consegue salvar o perfil.
A interface sozinha mostra uma única mensagem de erro. Os sinais HTTP podem revelar situações muito diferentes:
- →Uma requisição PATCH foi enviada, mas o servidor retornou 400 porque um campo era inválido.
- →A requisição foi enviada como POST, embora o backend espere PATCH.
- →O servidor retornou 403 porque o papel não tem a permissão necessária.
- →O cliente enviou o Content-Type errado.
- →A operação teve sucesso, mas o frontend não sabe tratar 204 No Content.
- →A requisição tem sucesso, mas o cache ou uma recarga da página mostra dados antigos.
Tudo isso pode parecer um único bug de “o perfil não salva”. Para a equipe, são seis classes diferentes de problemas. Método, código de status e cabeçalhos ajudam a identificar onde investigar.
O que QA precisa verificar
- →Qual método foi usado.
- →Qual URL foi chamada.
- →Quais cabeçalhos principais foram enviados.
- →Qual código de status foi retornado.
- →Quais cabeçalhos voltaram.
- →Se o corpo corresponde ao significado do cenário.
Com uma abordagem sistemática, os logs de rede deixam de parecer “ruído” e passam a revelar uma estrutura clara.
Principais conclusões para QA
- →O método expressa a intenção do cliente.
- →O código de status informa o resultado técnico do processamento.
- →Os cabeçalhos transmitem contexto essencial para requisições e respostas.
- →200 OK não garante que um cenário de negócio tenha sido concluído corretamente.
- →Muitos defeitos são mais fáceis de isolar quando você interpreta método, status e cabeçalhos em conjunto.
Leitura adicional
- →Nesta base de conhecimento: HTTP e HTTPS
- →Nesta base de conhecimento: Autenticação e autorização
- →Recurso externo: MDN: códigos de status de respostas HTTP