Chapitre 13
Les codes HTTP

Nous avons évoqué HTTP dans le chapitre traitant des protocoles de communication. Nous l'avions pris pour exemple, car c'est l'un des protocoles les plus répandus et connus du grand public. C'est lui qui est utilisé dans la communication entre les clients web et les serveurs web.

Les clients web, comme Chrome ou Firefox, communiquent avec des machines (les serveurs) pour obtenir des données sur le web, comme le contenu d'un site ou d'autres ressources.

Le protocole HTTP a mis en place des codes qui sont retournés dans chaque réponse d'un serveur vers un client. Ils aident le client à mieux gérer la réponse et à comprendre son contenu.

Tu as sûrement déjà rencontré un site qui t'affiche directement sur une page certains de ces codes, notamment en cas d'erreur. Par exemple, le fameux "404, page introuvable".

Pour en voir d'autres, ouvre ta console de navigateur (F12 sous Chrome) et va dans l'onglet réseau. En cliquant sur une ligne, tu verras le détail des requêtes et de leurs réponses.


Les codes sont des nombres entre 100 et 599 divisés en 5 catégories :

• 1xx : informationnel, la requête a été reçue et est en cours de traitement.
• 2xx : succès.
• 3xx : redirection, une action supplémentaire est nécessaire pour compléter la requête.
• 4xx : erreur côté client.
• 5xx : erreur côté serveur.

Il existe aujourd'hui 75 codes HTTP, dont une quinzaine sont utilisés quotidiennement par les développeurs :

• 200 : OK. La requête a réussi.
• 201 : Created. Une ressource a été créée avec succès. Par exemple la création d’un utilisateur.
• 202 : Accepted. La requête a été acceptée, mais n’est pas encore traitée. Le serveur informe alors le client : "j'ai bien reçu ta requête, je vais la traiter dans mon coin, tu peux retourner à tes occupations".
• 204 : No Content. La requête a réussi, mais il n'y a pas de contenu à renvoyer. Souvent utilisé pour les mises à jour ou les suppressions.
• 301 : Moved Permanently. La ressource a été déplacée de façon permanente. C'est indispensable quand on change les URL d'un site, pour rediriger les liens déjà dans la nature vers la nouvelle page. Ça permet non seulement de ne pas perdre les utilisateurs, mais aussi aux moteurs de recherche de comprendre la situation et de garder le référencement de la page.
• 304 : Not Modified. Très utilisé pour que le back indique au front que le contenu qu'il connaît est toujours d'actualité. Ça évite de tout retransmettre et d'encombrer le réseau.
• 400 : Bad Request. La requête est invalide. Elle est mal formatée, il manque un champ, la valeur est du mauvais type etc...
• 401 : Unauthorized. L'utilisateur n’est pas authentifié. Par exemple, lorsque j'essaie d'appeler une fonctionnalité "ajout aux favoris" sans être connecté sur le site.
• 403 : Forbidden. L'utilisateur n'est pas autorisé à faire cette action. Par exemple, accéder à une page réservée aux administrateurs.
• 404 : Not Found. La ressource n'existe pas.
• 405 : Method Not Allowed. On essaie d'exécuter une fonctionnalité non existante sur une ressource. Par exemple, on essaie de modifier les détails d'un compte client, mais le développeur n'a mis à disposition que la possibilité d'en créer depuis zéro.
• 409 : Conflict. On l'utilise quand une requête n'a pas de sens d'un point de vue métier. Par exemple, on demande la création d'un compte avec un email déjà utilisé.
• 429 : Too Many Requests. Des protections sont mises en place pour éviter de saturer l'infrastructure de production. Ça sert surtout contre les attaques par Déni de Service Distribuée (DDoS), quand des méchants pirates utilisent les caméras de surveillance des bébés pour envoyer des millions de requêtes vers ton site.
  
  C'est aussi très utile lors d'événements ponctuels pour gérer des pics de trafic anormaux. À L'Équipe, c'est par exemple ce qu'on retourne aux clients un soir de match exceptionnel du PSG.
• 500 : Internal Server Error. Une erreur côté serveur, souvent à cause d’un bug ou d’un problème inattendu.
• 502 : Bad Gateway. Dans les grosses structures avec un fort trafic, les navigateurs web n'envoient pas directement des requêtes aux serveurs qui exécutent le code métier. La requête passe d'abord par un intermédiaire qui va gérer du cache et la sécurité. Cet intermédiaire peut retourner une 502 quand lui-même s'est vu retourner une erreur par le serveur qu'il protège.
• 503 : Service Unavailable. Le serveur est temporairement indisponible, il est probablement en cours de maintenance.
• Et le code le plus important de tous : le 418, "je suis une théière". Il a été mis en place en 1998 pour un poisson d'avril dans la définition du "protocole de contrôle des théières". C'est le code qui doit être retourné si on demande à une théière de nous faire un café. Aujourd'hui, il en reste quelques traces dans les logiciels, notamment en tant qu'œuf de pâques (fonctionnalité cachée).

Jusqu'à présent, chaque fois que j'ai évoqué les clients HTTP, je t'ai parlé des plus connus : les navigateurs web. Ils permettent les échanges sur le Web entre des personnes utilisant une interface graphique et un serveur.

Dans le backend, nous construisons souvent des architectures découpées en petits morceaux. Ils communiquent également, la plupart du temps, par HTTP. Il y a donc là aussi un client.

Les développeurs utilisent des clients spécialisés, conçus uniquement pour envoyer des requêtes et recevoir des réponses. Elles sont directement transmises au reste du logiciel sans être interprétées.
C'est pourquoi les codes HTTP sont cruciaux pour nous autres développeurs. Ils nous permettent de mieux comprendre ce que contient cette réponse pour décider quoi en faire : la transformer, l'analyser, la mettre en cache, la rejeter, relancer une requête...