"Se um trabalhador quiser fazer bem o seu trabalho, ele deve primeiro afiar suas ferramentas." - Confúcio, "Os Analectos de Confúcio. Lu Linggong"
Primeira página > Programação > A referência definitiva para códigos de status HTTP em design de API

A referência definitiva para códigos de status HTTP em design de API

Publicado em 17/11/2024
Navegar:191

The Ultimate Reference for HTTP Status Codes in API Design

No mundo do desenvolvimento web e design de API, os códigos de status HTTP desempenham um papel crucial na comunicação do resultado das solicitações entre clientes e servidores. Esses códigos fornecem uma maneira padronizada de indicar condições, sucessos ou erros específicos que ocorrem durante o processamento de solicitações HTTP. Compreender esses códigos de status é essencial para os desenvolvedores, pois ajuda na depuração, no tratamento de erros e na criação de aplicativos mais robustos.

1. 1xx Informativo

Esses códigos de status indicam uma resposta provisória. Eles raramente são usados ​​na prática, mas podem ser úteis em determinados cenários.

  • 100 Continue: O servidor recebeu os cabeçalhos da solicitação e o cliente deve prosseguir para enviar o corpo da solicitação.
  • 101 protocolos de comutação: o solicitante solicitou ao servidor para trocar de protocolo e o servidor concordou em fazê-lo.

2. Sucesso 2xx

Esses códigos de status indicam que a solicitação do cliente foi recebida, compreendida e aceita com sucesso.

  • 200 OK: A solicitação foi bem-sucedida e a resposta contém os dados ou resultados solicitados.
    • Exemplo: recuperar informações do perfil de um usuário.
  • 201 Criado: a solicitação foi bem-sucedida e um novo recurso foi criado.
    • Exemplo: criar uma nova conta de usuário ou postar uma nova entrada no blog.
  • 204 Sem conteúdo: O servidor processou a solicitação com êxito, mas não está retornando nenhum conteúdo.
    • Exemplo: atualizar as configurações de um usuário onde nenhum corpo de resposta é necessário.
  • 206 Conteúdo Parcial: O servidor está entregando apenas parte do recurso devido a um cabeçalho de intervalo enviado pelo cliente.
    • Exemplo: streaming de conteúdo de vídeo ou download de arquivos grandes em partes.

3. Redirecionamento 3xx

Esses códigos de status indicam que ações adicionais precisam ser tomadas pelo agente do usuário para atender à solicitação.

  • 301 movido permanentemente: o recurso solicitado foi movido permanentemente para um novo URL.
  • 302 Encontrado: o recurso solicitado reside temporariamente em um URL diferente.
  • 304 Not Modified: Indica que o recurso não foi modificado desde a versão especificada pelos cabeçalhos da solicitação.

4. Erro do cliente 4xx

Esses códigos de status destinam-se a situações em que o cliente parece ter errado.

  • 400 Bad Request: O servidor não pode processar a solicitação devido a sintaxe inválida ou entrada incorreta.

    • Exemplo: Envio de JSON malformado no corpo da solicitação.
    • Uso: use quando a própria solicitação estiver malformada ou contiver parâmetros inválidos.
  • 401 Não autorizado: a solicitação requer autenticação do usuário.

    • Exemplo: tentativa de acessar um endpoint de API protegido sem fornecer credenciais válidas.
    • Uso: use quando a autenticação for necessária e não tiver sido fornecida ou for inválida.
  • 403 Proibido: O servidor entende a solicitação, mas se recusa a autorizá-la.

    • Exemplo: um usuário tentando acessar recursos somente de administrador.
    • Uso: Use quando o usuário está autenticado mas não tem permissão para a operação solicitada.
  • 404 Not Found: O recurso solicitado não foi encontrado no servidor.

    • Exemplo: tentativa de recuperar um perfil de usuário excluído.
    • Uso: Use quando o recurso solicitado não existe.
  • 405 Método não permitido: O método especificado na solicitação não é permitido para o recurso identificado pelo URI da solicitação.

    • Exemplo: Envio de uma solicitação POST para um endpoint que aceita apenas solicitações GET.
  • Conflito 409: a solicitação não pôde ser processada devido a um conflito com o estado atual do recurso.

    • Exemplo: Tentativa de criar um usuário com um e-mail que já existe no sistema.
    • Uso: Use quando houver um conflito com o estado atual do recurso, como entradas duplicadas.
  • 422 Entidade não processável: O servidor entende o tipo de conteúdo e a sintaxe da solicitação, mas não pode processar as instruções contidas.

    • Exemplo: envio de um formulário com dados inválidos que falha na validação do lado do servidor.
    • Uso: use para erros de validação onde a sintaxe da solicitação está correta, mas os dados estão semanticamente incorretos.
  • 429 Muitas solicitações: o usuário enviou muitas solicitações em um determinado período ("limitação de taxa").

    • Exemplo: implementação de limitação de taxa de API para evitar abusos.

5. Erro de servidor 5xx

Esses códigos de status indicam casos em que o servidor está ciente de que encontrou um erro ou é incapaz de executar a solicitação.

  • 500 Internal Server Error: uma mensagem de erro genérica indicando que o servidor encontrou uma condição inesperada que o impediu de atender à solicitação.

    • Exemplo: uma exceção não tratada ocorre no código do lado do servidor.
  • 501 Não implementado: O servidor não oferece suporte à funcionalidade necessária para atender à solicitação.

    • Exemplo: usando um novo método HTTP que o servidor não reconhece.
  • 502 Bad Gateway: O servidor, enquanto atuava como gateway ou proxy, recebeu uma resposta inválida do servidor upstream.

    • Exemplo: um servidor proxy reverso não pode se conectar ao servidor de origem.
  • 503 Serviço indisponível: O servidor atualmente não consegue lidar com a solicitação devido a sobrecarga temporária ou manutenção.

    • Exemplo: um servidor está passando por manutenção programada ou com alto tráfego.
  • 504 Gateway Timeout: O servidor, enquanto atuava como gateway ou proxy, não recebeu uma resposta oportuna do servidor upstream.

    • Exemplo: ocorre um tempo limite enquanto aguarda uma resposta de uma API de terceiros.

Melhores práticas para usar códigos de status HTTP

  1. Seja específico: use o código de status mais específico que se aplica à situação. Isso ajuda os clientes a entender exatamente o que aconteceu e como responder.

  2. Uso consistente: mantenha a consistência na forma como você usa códigos de status em sua API. Isso torna mais fácil para os desenvolvedores trabalharem com sua API.

  3. Forneça informações adicionais: junto com o código de status, inclua uma mensagem de erro detalhada no corpo da resposta, quando apropriado. Isso pode ajudar na depuração e melhorar a experiência do desenvolvedor.

  4. Considerações de segurança: Tenha cuidado ao revelar muitas informações nas respostas de erro, especialmente para erros 4xx e 5xx. Evite expor detalhes confidenciais sobre a arquitetura ou implementação do seu sistema.

  5. Documentação: documente claramente quais códigos de status sua API usa e em quais circunstâncias. Isso ajuda os consumidores de API a entender como interpretar e lidar com diferentes respostas.

Ao compreender e implementar adequadamente os códigos de status HTTP, os desenvolvedores podem criar APIs e aplicativos da web mais robustos, claros e fáceis de usar. Esses códigos servem como uma ferramenta de comunicação crucial entre clientes e servidores, ajudando a agilizar o tratamento de erros e a melhorar a confiabilidade geral do sistema.

Declaração de lançamento Este artigo foi reproduzido em: https://dev.to/shanu001x/the-ultimate-reference-for-http-status-codes-in-api-design-77b?1 Se houver alguma violação, entre em contato com study_golang@163 .com para excluí-lo
Tutorial mais recente Mais>

Isenção de responsabilidade: Todos os recursos fornecidos são parcialmente provenientes da Internet. Se houver qualquer violação de seus direitos autorais ou outros direitos e interesses, explique os motivos detalhados e forneça prova de direitos autorais ou direitos e interesses e envie-a para o e-mail: [email protected]. Nós cuidaremos disso para você o mais rápido possível.

Copyright© 2022 湘ICP备2022001581号-3