Códigos de Status HTTP: Guia de Referência Completo

31 de março de 2026 · 12 min de leitura

O Que São Códigos de Status HTTP?

Códigos de status HTTP são números de três dígitos retornados por um servidor em resposta à solicitação de um cliente. Eles indicam se a solicitação foi bem-sucedida, redirecionada ou resultou em erro. Toda vez que seu navegador carrega uma página, chama uma API ou envia um formulário, o servidor responde com um código de status.

Pense nos códigos de status como a forma do servidor comunicar o que aconteceu com sua solicitação. Assim como um semáforo indica se você deve parar ou seguir, os códigos de status informam à sua aplicação se deve prosseguir, tentar novamente ou lidar com um erro.

Os códigos de status são agrupados em cinco categorias com base em seu primeiro dígito:

• 1xx (Informacional): Solicitação recebida, processamento continua
• 2xx (Sucesso): Solicitação recebida, compreendida e aceita
• 3xx (Redirecionamento): Ação adicional necessária para completar a solicitação
• 4xx (Erro do Cliente): A solicitação contém um erro do lado do cliente
• 5xx (Erro do Servidor): O servidor falhou ao atender uma solicitação válida

Como os Códigos de Status Funcionam

Quando um cliente (como seu navegador ou um cliente de API) faz uma solicitação HTTP, o servidor a processa e retorna uma resposta. Esta resposta sempre inclui um código de status na primeira linha, seguido por cabeçalhos e um corpo opcional.

Veja como uma resposta HTTP típica se parece:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 1234

{"status": "success", "data": {...}}

O código de status aparece logo após a versão HTTP. Neste exemplo, 200 OK informa ao cliente que a solicitação foi bem-sucedida.

Os códigos de status servem a múltiplos propósitos:

• Comunicação: Eles fornecem uma forma padronizada para os servidores comunicarem resultados
• Tratamento de erros: Aplicações podem lidar programaticamente com diferentes cenários com base no código
• Depuração: Desenvolvedores podem identificar rapidamente onde ocorrem problemas no ciclo de solicitação-resposta
• SEO: Mecanismos de busca usam códigos de status para entender como indexar conteúdo
• Cache: Navegadores e CDNs usam códigos para determinar o comportamento de cache

1xx Informacional

Códigos de status informacionais indicam que o servidor recebeu a solicitação e está continuando a processá-la. Estas são respostas provisórias e raramente são vistas na navegação web cotidiana, mas são importantes para certos protocolos e otimizações.

100 Continue

O servidor recebeu os cabeçalhos da solicitação e o cliente deve prosseguir para enviar o corpo. Isso é usado com uploads grandes onde o cliente envia um cabeçalho Expect: 100-continue para verificar se o servidor aceitará a solicitação antes de enviar a carga completa.

Esta otimização evita desperdiçar largura de banda em solicitações que serão rejeitadas. Por exemplo, se você está enviando um arquivo de vídeo de 500MB, você não quer enviar todos esses dados apenas para descobrir que o servidor irá rejeitá-lo devido a falha de autenticação.

POST /upload HTTP/1.1
Host: api.example.com
Content-Length: 524288000
Expect: 100-continue

// Servidor responde com 100 Continue
// Cliente então envia o corpo da solicitação

101 Switching Protocols

O servidor concorda em mudar de protocolo conforme solicitado pelo cliente. Mais comumente visto ao atualizar de HTTP para WebSocket usando o cabeçalho Upgrade: websocket.

WebSockets permitem comunicação bidirecional em tempo real entre cliente e servidor, o que é essencial para aplicações de chat, atualizações ao vivo e ferramentas colaborativas.

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade

// Servidor responde com 101 Switching Protocols

103 Early Hints

Este código de status relativamente novo permite que o servidor envie cabeçalhos preliminares antes da resposta final. É frequentemente usado para começar a pré-carregar recursos como CSS, fontes e arquivos JavaScript enquanto o servidor ainda está preparando a resposta principal.

Early Hints pode melhorar significativamente os tempos de carregamento de página ao permitir que navegadores comecem a baixar recursos críticos mais cedo no processo de carregamento da página.

2xx Sucesso

Códigos de sucesso são o que você quer ver. Eles indicam que a solicitação foi recebida, compreendida e aceita com sucesso. Diferentes códigos 2xx fornecem informações detalhadas sobre exatamente como a solicitação foi processada.

200 OK

A resposta de sucesso padrão. A solicitação foi bem-sucedida e o corpo da resposta contém os dados solicitados. Este é o código de status mais comum na web.

Use 200 OK para solicitações GET bem-sucedidas que retornam dados, solicitações POST bem-sucedidas que retornam dados do recurso criado, e solicitações PUT/PATCH bem-sucedidas que retornam dados do recurso atualizado.

GET /api/users/123 HTTP/1.1

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 123, "name": "John Doe", "email": "[email protected]"}

201 Created

Um novo recurso foi criado com sucesso. Esta é a resposta apropriada para solicitações POST que criam novos recursos. A resposta deve incluir um cabeçalho Location apontando para o recurso recém-criado.

POST /api/users HTTP/1.1
Content-Type: application/json

{"name": "Jane Smith", "email": "[email protected]"}

HTTP/1.1 201 Created
Location: /api/users/124
Content-Type: application/json

{"id": 124, "name": "Jane Smith", "email": "[email protected]"}

202 Accepted

A solicitação foi aceita para processamento, mas o processamento não foi concluído. Isso é útil para operações assíncronas onde o servidor enfileira a solicitação para processamento posterior.

Casos de uso comuns incluem processamento em lote, envio de e-mail, codificação de vídeo e outras operações de longa duração que não devem bloquear a resposta HTTP.

204 No Content

A solicitação foi bem-sucedida, mas não há conteúdo para retornar. Isso é comumente usado para solicitações DELETE ou solicitações PUT/PATCH onde o cliente não precisa que o recurso atualizado seja retornado.

Usar 204 No Content em vez de 200 OK com um corpo vazio economiza largura de banda e comunica claramente a intenção.

DELETE /api/users/123 HTTP/1.1

HTTP/1.1 204 No Content

206 Partial Content

O servidor está entregando apenas parte do recurso devido a um cabeçalho de intervalo enviado pelo cliente. Isso permite downloads retomáveis e streaming de vídeo onde o cliente solicita intervalos de bytes específicos.

Players de vídeo usam isso extensivamente para permitir buscar diferentes partes de um vídeo sem baixar o arquivo inteiro primeiro.

3xx Redirecionamento

Códigos de redirecionamento indicam que o cliente precisa tomar ação adicional para completar a solicitação. Estes são cruciais para gerenciamento de URL, SEO e manutenção de compatibilidade retroativa quando recursos são movidos.

301 Moved Permanently

O recurso foi movido permanentemente para uma nova URL especificada no cabeçalho Location. Navegadores e mecanismos de busca devem atualizar seus registros para usar a nova URL.

Este é o código de status ideal para redirecionamentos permanentes. Mecanismos de busca transferirão o valor de SEO da URL antiga para a nova, e navegadores farão cache do redirecionamento.

GET /old-page HTTP/1.1

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

302 Found (Temporary Redirect)

O recurso reside temporariamente em uma URL diferente. O cliente deve continuar a usar a URL original para solicitações futuras. Mecanismos de busca não transferirão valor de SEO com este redirecionamento.

Casos de uso comuns incluem testes A/B, páginas de manutenção e páginas promocionais temporárias.

303 See Other

A resposta à solicitação pode ser encontrada em outra URL usando GET. Isso é comumente usado após solicitações POST para redirecionar para uma página de resultado, prevenindo envios duplicados de formulário se o usuário atualizar a página.

Isso implementa o padrão Post/Redirect/Get, que é uma melhor prática para formulários web.

304 Not Modified

O recurso não foi modificado desde a versão especificada nos cabeçalhos da solicitação (If-Modified-Since ou If-None-Match). O cliente pode usar sua versão em cache.

Isso reduz drasticamente o uso de largura de banda e melhora o desempenho ao evitar transferência desnecessária de dados quando o conteúdo não mudou.

307 Temporary Redirect

Similar ao 302, mas garante que o método da solicitação não mudará quando redirecionado. Se a solicitação original foi POST, a solicitação redirecionada também será POST.

308 Permanent Redirect

Similar ao 301, mas garante que o método da solicitação não mudará. Esta é a versão moderna e mais precisa do 301 para APIs e aplicações que precisam de preservação estrita do método.

4xx Erros do Cliente

Códigos de erro do cliente indicam que a solicitação contém sintaxe incorreta ou não pode ser atendida devido a problemas do lado do cliente. Esses erros significam que o cliente precisa modificar a solicitação antes de tentar novamente.

400 Bad Request

O servidor não pode processar a solicitação devido a sintaxe malformada, enquadramento de mensagem de solicitação inválido ou roteamento de solicitação enganoso. Este é um erro genérico para solicitações que não se encaixam em outras categorias 4xx.

Causas comuns incluem JSON malformado, campos obrigatórios ausentes, tipos de dados inválidos ou solicitações que violam restrições da API.

POST /api/users HTTP/1.1
Content-Type: application/json

{"name": "John", "email": "not-an-email"}

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error": "Invalid email format"}

401 Unauthorized

Autenticação é necessária e falhou ou não foi fornecida. Apesar do nome, isso na verdade significa "não autenticado" – o cliente precisa fornecer credenciais válidas.

A resposta deve incluir um cabeçalho WWW-Authenticate indicando o método de autenticação necessário.

GET /api/protected-resource HTTP/1.1

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api"

{"error": "Authentication required"}

403 Forbidden

O servidor entendeu a solicitação mas se recusa a autorizá-la. Diferente do 401, autenticação não ajudará – o cliente não tem permissão para acessar este recurso.

Use isso quando um usuário está autenticado mas não tem as permissões necessárias, ou quando o acesso é restrito por endereço IP, limitação de taxa ou outras políticas.