Introduction aux codes de statut HTTP

Les codes de statut HTTP (Status Code) servent à indiquer le résultat d'une requête du client par le serveur. Dans les entretiens techniques, ils sont généralement classés en cinq catégories principales.

1xx : Information

Ces codes signalent que la requête a été reçue et que le traitement continue. Ils sont rarement rencontrés en développement pratique.

• 100 Continue : Le client peut envoyer le corps de la requête. Utile pour les transferts de fichiers volumineux.

2xx : Succès

La requête a été traitée avec succès.

• 200 OK : Requête réussie, le serveur retourne les données demendées.
• 201 Created : Requête réussie avec création d'une nouvelle ressource, typiquement après une requête POST (par exemple, l'enregistrement d'un nouvel utilisateur).
• 204 No Content : Requête réussie mais aucun contenu renvoyé. Souvent utilisé pour les suppressions ou les mises à jour simples.

3xx : Redirection

Une action suplémentaire est nécessaire pour compléter la requête.

• 301 Moved Permanently : L'adresse de la ressource a changé de façon permanente, par exemple lors d'un changement de domaine.
• 302 Found : Redirection temporaire, comme une redirection vers une page de connexion après une session expirée.
• 304 Not Modified : La ressource n'a pas été modifiée ; le client peut utiliser le cache. Cela optimise la bande passante et accélère le chargement.

4xx : Erreur du client

Ces codes indiquent une erreur dans la requête du client. C'est la catégorie la plus fréquente.

• 400 Bad Request : Format de requête incorrect, par exemple envoi de données texte au lieu de JSON.
• 401 Unauthorized : Authentification requise ou échouée, comme un token invalide.
• 403 Forbidden : Accès refusé malgré l'authentification, par exemple un utilisateur standard tentant d'accéder à une zone administrateur.
• 404 Not Found : Ressource introuvable, due à une URL erronée ou une suppression définitive.
• 405 Method Not Allowed : Méthode HTTP non supportée, par exemple utilisation de POST sur une API ne acceptant que GET.

5xx : Erreur du serveur

Ces codes signalent un problème côté serveur, nécessitant souvent une intervention technique.

• 500 Internal Server Error : Erreur interne du serveur, comme un bug dans le code, une exception non gérée ou une panne de connexion à la base de données.
• 502 Bad Gateway : Erreur de passerelle, typiquement quand Nginx ne peut pas contacter un service backend (par exemple, un service Python ou Java indisponible).
• 503 Service Unavailable : Serveur temporairement indisponible, souvent dû à une surcharge ou à une maintenance.
• 504 Gateway Timeout : Délai d'attente dépassé pour la réponse du serveur backend, par exemple lors d'une requête longue comme une recherche dans une grande base de données.

Analyse technique : Le code 200 garantit-il un fonctionnement correct ?

Dans un entretien, on peut demander si un code de statut HTTP 200 signifie toujours que tout fonctionne bien. Voici une réponse technique détaillée.

Niveau HTTP : 200 indique uniquement le succès de la requête

Non, un code HTTP 200 ne garantit pas l'absence d'erreurs métier. Il signifie que la requête a été traitée avec succès par le serveur, mais le contenu retourné peut contenir des erreurs logiques.

Exemple de réponse avec un code HTTP 200 mais une erreur métier :

{
  "status": 200,
  "erreur": "Échec de l'accès à la base de données",
  "donnees": null
}

Ici, le code HTTP est 200, mais l'opération a échoué en raison d'une erreur applicative.

Niveau métier : Systèmes utilisant des codes internes avec HTTP 200

De nombreux systèmes distinguent le code HTTP (succès réseau) du code métier (succès applicatif). Par exemple :

{
  "reponseCode": 0,
  "message": "Opération réussie",
  "resultat": {...}
}
ou
{
  "reponseCode": 5001,
  "message": "Utilisateur non trouvé",
  "resultat": null
}

Ainsi, un code HTTP 200 ne garantit pas le succès des opérations métier.

Cas pratiques en développement

• Cas 1 : Erreur métier avec code 200 - Par exemple, une tentative de connexion échouée : ``` { "reponseCode": 1002, "detail": "Identifiants incorrects" }

  
   Le code HTTP reste 200 car la requête elle-même est valide, mais l'authentification a échoué.
  

• Cas 2 : Erreur logique avec code 200 - Un code backend peut capturer des exceptions et renvoyer une réponse structurée : ``` try { chercherUtilisateur(id); } catch (Exception e) { return { "reponseCode": 500, "message": "Erreur de base de données" }; }

  
   Le code HTTP est 200, mais l'opération a échoué en raison d'une exception.
  

• Cas 3 : Données incohérentes - Une API peut renvoyer des données valides mais incorrectes : ``` { "utilisateurId": 1, "solde": -50000 }

  
   Le code HTTP est 200, mais la valeur négative indique une possible erreur dans la logique de calcul.
  
  

En résumé, un développeur doit toujours vérifier à la fois le code HTTP et les données retournées pour diagnostiquer les problèmes.