La référence ultime pour les codes d'état HTTP dans la conception d'API

Dans le monde du développement Web et de la conception d'API, les codes d'état HTTP jouent un rôle crucial dans la communication du résultat des requêtes entre les clients et les serveurs. Ces codes fournissent un moyen standardisé d'indiquer des conditions spécifiques, des succès ou des erreurs qui se produisent lors du traitement des requêtes HTTP. Comprendre ces codes d'état est essentiel pour les développeurs, car cela aide au débogage, à la gestion des erreurs et à la création d'applications plus robustes.

1. 1xx informatif

Ces codes d'état indiquent une réponse provisoire. Ils sont rarement utilisés dans la pratique mais peuvent être utiles dans certains scénarios.

• 100 Continue : Le serveur a reçu les en-têtes de requête et le client doit procéder à l'envoi du corps de la requête.
• 101 protocoles de commutation : le demandeur a demandé au serveur de changer de protocole et le serveur a accepté de le faire.

2. 2xx Succès

Ces codes de statut indiquent que la demande du client a été reçue, comprise et acceptée avec succès.

• 200 OK : La demande a réussi et la réponse contient les données ou le résultat demandés.
  • Exemple : Récupération des informations de profil d'un utilisateur.
• 201 Créé : La demande a abouti et une nouvelle ressource a été créée.
  • Exemple : création d'un nouveau compte utilisateur ou publication d'une nouvelle entrée de blog.
• 204 No Content : Le serveur a traité avec succès la demande mais ne renvoie aucun contenu.
  • Exemple : mise à jour des paramètres d'un utilisateur lorsqu'aucun corps de réponse n'est nécessaire.
• 206 Contenu partiel : Le serveur ne fournit qu'une partie de la ressource en raison d'un en-tête de plage envoyé par le client.
  • Exemple : diffusion de contenu vidéo ou téléchargement de fichiers volumineux en morceaux.

3. Redirection 3xx

Ces codes d'état indiquent que des mesures supplémentaires doivent être prises par l'agent utilisateur pour répondre à la demande.

• 301 Déplacé de façon permanente : La ressource demandée a été définitivement déplacée vers une nouvelle URL.
• 302 trouvés : la ressource demandée réside temporairement sous une URL différente.
• 304 Non modifié : Indique que la ressource n'a pas été modifiée depuis la version spécifiée par les en-têtes de la requête.

4. Erreur client 4xx

Ces codes de statut sont destinés aux situations dans lesquelles le client semble s'être trompé.

• 400 Bad Request : Le serveur ne peut pas traiter la demande en raison d'une syntaxe non valide ou d'une mauvaise saisie.

  • Exemple : Envoi de JSON malformé dans le corps de la requête.
  • Utilisation : à utiliser lorsque la requête elle-même est mal formée ou contient des paramètres non valides.

• 401 Non autorisé : La demande nécessite une authentification de l'utilisateur.

  • Exemple : Tentative d'accès à un point de terminaison d'API protégé sans fournir d'informations d'identification valides.
  • Utilisation : à utiliser lorsque l'authentification est requise et n'a pas été fournie ou n'est pas valide.

• 403 Forbidden : Le serveur comprend la requête mais refuse de l'autoriser.

  • Exemple : un utilisateur essayant d'accéder aux fonctionnalités réservées aux administrateurs.
  • Utilisation : à utiliser lorsque l'utilisateur est authentifié mais n'a pas l'autorisation pour l'opération demandée.

• 404 Not Found : La ressource demandée est introuvable sur le serveur.

  • Exemple : Tentative de récupération d'un profil utilisateur supprimé.
  • Utilisation : à utiliser lorsque la ressource demandée n'existe pas.

• 405 Méthode non autorisée : La méthode spécifiée dans la requête n'est pas autorisée pour la ressource identifiée par l'URI de la requête.

  • Exemple : Envoi d'une requête POST à ​​un point de terminaison qui n'accepte que les requêtes GET.

• 409 Conflit : La demande n'a pas pu être traitée en raison d'un conflit avec l'état actuel de la ressource.

  • Exemple : Essayer de créer un utilisateur avec une adresse e-mail qui existe déjà dans le système.
  • Utilisation : à utiliser en cas de conflit avec l'état actuel de la ressource, tel que des entrées en double.

• 422 Entité non traitable : Le serveur comprend le type de contenu et la syntaxe de la requête, mais ne peut pas traiter les instructions contenues.

  • Exemple : Soumission d'un formulaire avec des données non valides qui échoue à la validation côté serveur.
  • Utilisation : à utiliser pour les erreurs de validation où la syntaxe de la requête est correcte, mais les données sont sémantiquement incorrectes.

• 429 Trop de requêtes : L'utilisateur a envoyé trop de requêtes dans un laps de temps donné ("limitation du débit").

  • Exemple : mise en œuvre d'une limitation du débit de l'API pour éviter les abus.

5. Erreur de serveur 5xx

Ces codes d'état indiquent les cas dans lesquels le serveur est conscient qu'il a rencontré une erreur ou qu'il est autrement incapable d'exécuter la demande.

• 500 Erreur interne du serveur : Un message d'erreur générique indiquant que le serveur a rencontré une condition inattendue qui l'a empêché de répondre à la demande.

  • Exemple : Une exception non gérée se produit dans le code côté serveur.

• 501 Non implémenté : Le serveur ne prend pas en charge les fonctionnalités requises pour répondre à la demande.

  • Exemple : Utilisation d'une nouvelle méthode HTTP que le serveur ne reconnaît pas.

• 502 Bad Gateway : Le serveur, tout en agissant en tant que passerelle ou proxy, a reçu une réponse non valide du serveur en amont.

  • Exemple : Un serveur proxy inverse ne peut pas se connecter au serveur d'origine.

• Service 503 indisponible : Le serveur est actuellement incapable de traiter la demande en raison d'une surcharge temporaire ou d'une maintenance.

  • Exemple : Un serveur est en cours de maintenance planifiée ou connaît un trafic élevé.

• 504 Gateway Timeout : Le serveur, tout en agissant en tant que passerelle ou proxy, n'a pas reçu de réponse en temps opportun du serveur en amont.

  • Exemple : un délai d'attente se produit lors de l'attente d'une réponse d'une API tierce.

Meilleures pratiques d'utilisation des codes d'état HTTP

1. Soyez précis : utilisez le code de statut le plus spécifique qui s'applique à la situation. Cela aide les clients à comprendre exactement ce qui s'est passé et comment réagir.

2. Utilisation cohérente : maintenez la cohérence dans la façon dont vous utilisez les codes de statut dans votre API. Cela permet aux développeurs de travailler plus facilement avec votre API.

3. Fournir des informations supplémentaires : avec le code d'état, incluez un message d'erreur détaillé dans le corps de la réponse, le cas échéant. Cela peut aider au débogage et améliorer l'expérience du développeur.

4. Considérations de sécurité : Soyez prudent lorsque vous révélez trop d'informations dans les réponses aux erreurs, en particulier pour les erreurs 4xx et 5xx. Évitez d'exposer des détails sensibles sur l'architecture ou la mise en œuvre de votre système.

5. Documentation : documentez clairement les codes d'état que votre API utilise et dans quelles circonstances. Cela aide les consommateurs d'API à comprendre comment interpréter et gérer différentes réponses.

En comprenant et en implémentant correctement les codes d'état HTTP, les développeurs peuvent créer des API et des applications Web plus robustes, claires et conviviales. Ces codes constituent un outil de communication crucial entre les clients et les serveurs, contribuant à rationaliser la gestion des erreurs et à améliorer la fiabilité globale du système.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!