Códigos de Status HTTP

O servidor recebeu os headers e o cliente deve prosseguir com o envio do corpo da solicitação.

O servidor está mudando protocolos conforme solicitado pelo cliente (ex: upgrade para WebSocket).

O servidor recebeu e está processando a solicitação, mas ainda não há resposta disponível (WebDAV).

Usado para retornar alguns headers antes da mensagem final, permitindo ao navegador pré-carregar recursos.

A solicitação foi bem-sucedida. O significado depende do método HTTP: GET retorna o recurso, POST retorna o resultado da ação.

A solicitação foi bem-sucedida e um novo recurso foi criado. Tipicamente usado como resposta a solicitações POST.

A solicitação foi aceita para processamento, mas ainda não foi concluída. Usado para operações assíncronas.

O servidor processou a solicitação com sucesso mas não retorna conteúdo. Resposta comum para operações DELETE.

O servidor entrega apenas parte do recurso devido a um header Range enviado pelo cliente.

Resposta que transmite informações sobre múltiplos recursos onde vários códigos de status podem ser apropriados (WebDAV).

O recurso foi movido permanentemente para uma nova URL. Os buscadores atualizarão seus links.

O recurso reside temporariamente em outra URL. O cliente deve continuar usando a URL original para futuras solicitações.

A resposta pode ser encontrada em outra URL usando GET. Frequentemente usado após POST para redirecionar a uma página de confirmação.

O recurso não foi modificado desde a última solicitação. Usado para cache — o cliente pode usar sua versão salva.

O recurso reside temporariamente em outra URL. Diferente do 302, o método de solicitação não deve mudar.

O recurso foi movido permanentemente. Diferente do 301, o método de solicitação não deve mudar.

O servidor não pode processar a solicitação devido a sintaxe malformada, parâmetros inválidos ou campos obrigatórios ausentes.

Autenticação é necessária. O cliente deve fornecer credenciais válidas (API key, token ou login) para acessar.

O servidor entendeu a solicitação mas se recusa a autorizá-la. Autenticação não ajudará — o usuário não tem permissão.

O recurso solicitado não foi encontrado no servidor. A URL pode estar incorreta ou o recurso pode ter sido excluído.

O método HTTP usado não é suportado para este recurso. Por exemplo, usar POST em um endpoint somente leitura.

O servidor esgotou o tempo de espera. O cliente demorou demais para enviar a solicitação completa.

A solicitação conflita com o estado atual do servidor. Comum em controle de versão ou ao tentar criar um recurso duplicado.

O recurso não está mais disponível e não estará novamente. Diferente do 404, esta é uma condição permanente.

O corpo da solicitação é maior do que o servidor aceita. Comum para limites de upload de arquivos.

O tipo de mídia do corpo da solicitação não é suportado. Por exemplo, enviar XML quando apenas JSON é aceito.

O servidor se recusa a preparar café porque é, permanentemente, um bule de chá. Uma piada do April Fools' do RFC 2324.

O servidor entende o conteúdo mas não pode processá-lo. Usado para erros de validação — a sintaxe está correta mas os dados são inválidos.

O usuário enviou muitas solicitações em um período de tempo (rate limiting). Verifique o header Retry-After.

O servidor encontrou uma condição inesperada que o impediu de atender a solicitação. Um erro genérico do servidor.

O servidor não suporta a funcionalidade necessária. O método pode não ser reconhecido.

O servidor, atuando como gateway ou proxy, recebeu uma resposta inválida do servidor upstream.

O servidor não pode atender a solicitação temporariamente devido a manutenção ou sobrecarga. Geralmente temporário.

O servidor, atuando como gateway ou proxy, não recebeu uma resposta a tempo do servidor upstream.