Codes de statut HTTP : Guide de référence complet

· 12 min de lecture

Table des matières

Que sont les codes de statut HTTP ?

Les codes de statut HTTP sont des nombres à trois chiffres renvoyés par un serveur en réponse à la requête d'un client. Ils indiquent si la requête a réussi, a été redirigée ou a entraîné une erreur. Chaque fois que votre navigateur charge une page, appelle une API ou soumet un formulaire, le serveur répond avec un code de statut.

Considérez les codes de statut comme la façon dont le serveur communique ce qui s'est passé avec votre requête. Tout comme un feu de circulation vous indique s'il faut vous arrêter ou continuer, les codes de statut indiquent à votre application s'il faut continuer, réessayer ou gérer une erreur.

Les codes de statut sont regroupés en cinq catégories en fonction de leur premier chiffre :

Référence rapide : Utilisez notre outil Recherche de codes de statut HTTP pour vérifier rapidement n'importe quel code de statut et voir des explications détaillées avec des exemples.

Comment fonctionnent les codes de statut

Lorsqu'un client (comme votre navigateur ou un client API) effectue une requête HTTP, le serveur la traite et renvoie une réponse. Cette réponse inclut toujours un code de statut dans la première ligne, suivi d'en-têtes et d'un corps optionnel.

Voici à quoi ressemble une réponse HTTP typique :

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

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

Le code de statut apparaît juste après la version HTTP. Dans cet exemple, 200 OK indique au client que la requête a réussi.

Les codes de statut servent plusieurs objectifs :

1xx Informationnels

Les codes de statut informationnels indiquent que le serveur a reçu la requête et continue de la traiter. Ce sont des réponses provisoires et elles sont rarement vues dans la navigation web quotidienne, mais elles sont importantes pour certains protocoles et optimisations.

100 Continue

Le serveur a reçu les en-têtes de la requête et le client doit procéder à l'envoi du corps. Ceci est utilisé avec les téléchargements volumineux où le client envoie un en-tête Expect: 100-continue pour vérifier si le serveur acceptera la requête avant d'envoyer la charge utile complète.

Cette optimisation évite de gaspiller de la bande passante sur des requêtes qui seront rejetées. Par exemple, si vous téléchargez un fichier vidéo de 500 Mo, vous ne voulez pas envoyer toutes ces données pour découvrir ensuite que le serveur le rejettera en raison d'un échec d'authentification.

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

// Le serveur répond avec 100 Continue
// Le client envoie ensuite le corps de la requête

101 Switching Protocols

Le serveur accepte de changer de protocole comme demandé par le client. Le plus souvent vu lors de la mise à niveau de HTTP vers WebSocket en utilisant l'en-tête Upgrade: websocket.

Les WebSockets permettent une communication bidirectionnelle en temps réel entre le client et le serveur, ce qui est essentiel pour les applications de chat, les mises à jour en direct et les outils collaboratifs.

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

// Le serveur répond avec 101 Switching Protocols

103 Early Hints

Ce code de statut relativement nouveau permet au serveur d'envoyer des en-têtes préliminaires avant la réponse finale. Il est souvent utilisé pour commencer à précharger des ressources comme les fichiers CSS, les polices et JavaScript pendant que le serveur prépare encore la réponse principale.

Early Hints peut améliorer considérablement les temps de chargement des pages en permettant aux navigateurs de commencer à télécharger les ressources critiques plus tôt dans le processus de chargement de la page.

Conseil de pro : La plupart des développeurs n'auront jamais besoin de gérer directement les codes 1xx. Ils sont généralement gérés automatiquement par les serveurs web et les bibliothèques HTTP. Concentrez plutôt votre gestion des erreurs sur les codes 4xx et 5xx.

2xx Succès

Les codes de succès sont ce que vous voulez voir. Ils indiquent que la requête a été reçue, comprise et acceptée avec succès. Différents codes 2xx fournissent des informations nuancées sur exactement comment la requête a été traitée.

200 OK

La réponse de succès standard. La requête a réussi et le corps de la réponse contient les données demandées. C'est le code de statut le plus courant sur le web.

Utilisez 200 OK pour les requêtes GET réussies qui renvoient des données, les requêtes POST réussies qui renvoient les données de la ressource créée, et les requêtes PUT/PATCH réussies qui renvoient les données de la ressource mise à jour.

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

Une nouvelle ressource a été créée avec succès. C'est la réponse appropriée pour les requêtes POST qui créent de nouvelles ressources. La réponse doit inclure un en-tête Location pointant vers la ressource nouvellement créée.

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

La requête a été acceptée pour traitement, mais le traitement n'est pas terminé. Ceci est utile pour les opérations asynchrones où le serveur met la requête en file d'attente pour un traitement ultérieur.

Les cas d'utilisation courants incluent le traitement par lots, l'envoi d'e-mails, l'encodage vidéo et d'autres opérations de longue durée qui ne devraient pas bloquer la réponse HTTP.

204 No Content

La requête a réussi, mais il n'y a pas de contenu à renvoyer. Ceci est couramment utilisé pour les requêtes DELETE ou les requêtes PUT/PATCH où le client n'a pas besoin que la ressource mise à jour soit renvoyée.

Utiliser 204 No Content au lieu de 200 OK avec un corps vide économise de la bande passante et communique clairement l'intention.

DELETE /api/users/123 HTTP/1.1

HTTP/1.1 204 No Content

206 Partial Content

Le serveur ne livre qu'une partie de la ressource en raison d'un en-tête de plage envoyé par le client. Cela permet les téléchargements reprenables et le streaming vidéo où le client demande des plages d'octets spécifiques.

Les lecteurs vidéo utilisent cela de manière extensive pour permettre de se déplacer vers différentes parties d'une vidéo sans télécharger d'abord le fichier entier.

Code de statut Nom Quand l'utiliser
200 OK Réponse de succès standard avec contenu
201 Created Ressource créée avec succès
202 Accepted Requête mise en file d'attente pour traitement asynchrone
204 No Content Succès sans corps de réponse nécessaire
206 Partial Content Renvoi de la plage d'octets demandée

3xx Redirection

Les codes de redirection indiquent que le client doit effectuer une action supplémentaire pour compléter la requête. Ceux-ci sont cruciaux pour la gestion des URL, le SEO et le maintien de la rétrocompatibilité lorsque les ressources se déplacent.

301 Moved Permanently

La ressource a été déplacée de façon permanente vers une nouvelle URL spécifiée dans l'en-tête Location. Les navigateurs et les moteurs de recherche doivent mettre à jour leurs enregistrements pour utiliser la nouvelle URL.

C'est le code de statut de référence pour les redirections permanentes. Les moteurs de recherche transféreront la valeur SEO de l'ancienne URL vers la nouvelle, et les navigateurs mettront en cache la redirection.

GET /old-page HTTP/1.1

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

Conseil de pro : Utilisez les redirections 301 lorsque vous avez déplacé définitivement du contenu. Utilisez 302 pour les déplacements temporaires. Se tromper peut nuire à votre SEO, car les moteurs de recherche les traitent très différemment.

302 Found (Redirection temporaire)

La ressource réside temporairement à une URL différente. Le client doit continuer à utiliser l'URL d'origine pour les requêtes futures. Les moteurs de recherche ne transféreront pas la valeur SEO avec cette redirection.

Les cas d'utilisation courants incluent les tests A/B, les pages de maintenance et les pages promotionnelles temporaires.

303 See Other

La réponse à la requête peut être trouvée à une autre URL en utilisant GET. Ceci est couramment utilisé après les requêtes POST pour rediriger vers une page de résultat, empêchant les soumissions de formulaire en double si l'utilisateur actualise.

Cela implémente le modèle Post/Redirect/Get, qui est une meilleure pratique pour les formulaires web.

304 Not Modified

La ressource n'a pas été modifiée depuis la version spécifiée dans les en-têtes de la requête (If-Modified-Since ou If-None-Match). Le client peut utiliser sa version en cache.

Cela réduit considérablement l'utilisation de la bande passante et améliore les performances en évitant le transfert de données inutile lorsque le contenu n'a pas changé.

307 Temporary Redirect

Similaire à 302, mais garantit que la méthode de requête ne changera pas lors de la redirection. Si la requête d'origine était POST, la requête redirigée sera également POST.

308 Permanent Redirect

Similaire à 301, mais garantit que la méthode de requête ne changera pas. C'est la version moderne et plus précise de 301 pour les API et les applications qui nécessitent une préservation stricte de la méthode.

4xx Erreurs client

Les codes d'erreur client indiquent que la requête contient une syntaxe incorrecte ou ne peut pas être satisfaite en raison de problèmes côté client. Ces erreurs signifient que le client doit modifier la requête avant de réessayer.

400 Bad Request

Le serveur ne peut pas traiter la requête en raison d'une syntaxe mal formée, d'un cadrage de message de requête invalide ou d'un routage de requête trompeur. C'est une erreur générique pour les requêtes qui ne correspondent pas aux autres catégories 4xx.

Les causes courantes incluent le JSON mal formé, les champs obligatoires manquants, les types de données invalides ou les requêtes qui violent les contraintes de l'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

L'authentification est requise et a échoué ou n'a pas été fournie. Malgré le nom, cela signifie en fait "non authentifié" – le client doit fournir des informations d'identification valides.

La réponse doit inclure un en-tête WWW-Authenticate indiquant la méthode d'authentification requise.

GET /api/protected-resource HTTP/1.1

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

{"error": "Authentication required"}

403 Forbidden

Le serveur a compris la requête mais refuse de l'autoriser. Contrairement à 401, l'authentification n'aidera pas – le client n'a pas la permission d'accéder à cette ressource.

Utilisez ceci lorsqu'un utilisateur est authentifié mais n'a pas les permissions nécessaires, ou lorsque l'accès est restreint par adresse IP, limitation de débit ou d'autres politiques.

📚 You May Also Like

API Testing Guide: Tools, Methods & Best Practices JWT Authentication: How JSON Web Tokens Work Web Performance Optimization: Speed Up Your Site