HTTP 201 Created: o que significa

O que este erro significa e como reconhecê-lo

• Um cliente de API, uma aplicação baseada em navegador, uma ferramenta de monitoramento ou um verificador informa 201 Created.
• A resposta pode incluir um objeto recém-criado, metadados do recurso ou um cabeçalho Location.
• O resultado pode ocorrer apenas para uma rota, um método HTTP, uma conta ou um payload de solicitação específico.
• Um 201 bem-sucedido pode vir acompanhado de avisos no nível da aplicação ou detalhes de validação no corpo da resposta.
• As verificações de DNS e TLS ainda podem ser bem-sucedidas porque um endpoint que se comunica por HTTP retornou uma resposta; essas verificações são independentes do status HTTP.

Causas principais, por probabilidade

1. Criação esperada de recurso: A rota cria intencionalmente um registro, uma conta, um upload, um job, um pedido ou outro recurso e retorna 201 após o sucesso.
2. Foi usado um método que cria recursos: O cliente enviou uma solicitação POST ou PUT para um endpoint projetado para criar um recurso. O método e a rota determinam se 201 é apropriado.
3. A solicitação foi repetida ou enviada para a rota errada: Um cliente, uma integração ou um formulário pode estar direcionando a solicitação para um endpoint de criação quando deveria atualizar um recurso existente ou usar outra URL.
4. O comportamento da aplicação ou do roteamento mudou: Uma implantação, um controller, um handler ou uma regra de rota pode ter alterado o status retornado para uma solicitação.
5. Um intermediário gerou ou modificou a resposta: Um reverse proxy, uma CDN, um WAF ou um gateway pode estar envolvido, especialmente quando os cabeçalhos diferem entre solicitações diretas e públicas.
6. A interpretação do cliente é enganosa: Uma regra de monitoramento pode classificar qualquer resposta HTTP que não seja de erro como incomum, embora 201 seja válido para aquele endpoint.

Como corrigir

Primeiro, decida se HTTP 201 é esperado

1. Registre a URL exata, o método HTTP, o corpo da solicitação ou os parâmetros relevantes, o contexto da conta e o horário. Não inclua senhas, cookies, tokens de acesso ou outros segredos nas anotações compartilhadas.
2. Verifique o comportamento documentado do endpoint ou o contrato da aplicação. Um endpoint de criação normalmente retorna 201; uma solicitação de página somente leitura normalmente não deve criar um recurso.
3. Inspecione o corpo e os cabeçalhos da resposta. Procure um cabeçalho Location, um identificador de recurso, o tipo de conteúdo, um ID da solicitação, informações de cache e qualquer aviso no nível da aplicação. Trate os cabeçalhos como evidências, não como prova de que um componente específico gerou a resposta.
4. Confirme se o cliente seguiu redirecionamentos ou informou uma resposta intermediária. Registre a resposta final separadamente de qualquer resposta anterior.

Se você é usuário de uma API ou visitante

1. Se a operação deveria criar algo, verifique na aplicação se o novo recurso existe antes de enviar a solicitação novamente.
2. Se a operação não deveria criar nada, interrompa as tentativas repetidas e verifique a rota, o método HTTP e a configuração do cliente.
3. Se a autenticação for necessária, faça login pelo fluxo normal da aplicação e repita a operação somente quando isso for seguro e autorizado.
4. Forneça ao responsável pelo site a URL e o método sem dados sensíveis, o horário, o status, os cabeçalhos relevantes da resposta e o ID da solicitação, se disponível. Nunca compartilhe credenciais, cookies de sessão ou segredos de API.

Se você é responsável pela aplicação ou pelo site

1. Reproduza a solicitação em um ambiente seguro ou com uma conta de teste autorizada. Capture o método, a URL, o status, os cabeçalhos da resposta e um corpo da resposta com os dados sensíveis ocultados.
2. Identifique o componente que produziu a resposta: handler da aplicação, servidor web, reverse proxy, CDN, WAF ou outro gateway. Compare os IDs de solicitação ou cabeçalhos de tempo gerados pelo servidor com os logs, quando disponíveis.
3. Inspecione os logs correspondentes da aplicação e da infraestrutura no horário registrado. Confirme se um recurso foi realmente criado e se a operação foi confirmada uma vez ou mais de uma vez.
4. Revise as alterações recentes em rotas, controllers, tratamento de solicitações, autenticação, regras de proxy e implantações. Preste atenção especial a clientes que podem repetir solicitações de criação não idempotentes.
5. Se 201 estiver incorreto para o endpoint, altere a regra mais específica da aplicação ou do roteamento que controla a resposta. Obtenha autorização e teste a alteração antes de aplicá-la em produção.
6. Teste novamente usando o mesmo método, URL e payload; depois, teste as rotas relacionadas de criação, leitura e atualização para garantir que os códigos de status esperados e o comportamento dos recursos continuem corretos.

Prevenção e como verificar a correção

• Defina os métodos HTTP e códigos de status esperados para cada rota pública, incluindo o comportamento de criação e de solicitações duplicadas.
• Teste as operações de criação, leitura e atualização com casos autenticados e não autenticados representativos após as implantações.
• Faça os clientes tratarem 201 explicitamente e verificarem o recurso retornado ou o cabeçalho Location antes de tentar novamente.
• Use identificadores de solicitação e mantenha os logs da aplicação, do proxy e do gateway por tempo suficiente para rastrear uma resposta inesperada.
• Monitore as taxas de códigos de status por rota e método, em vez de tratar todas as respostas 2xx como equivalentes.
• Mantenha as alterações de roteamento, autenticação, proxy e aplicação sob controle de versão e documente as respostas 201 intencionais.

Perguntas frequentes