Polar Code 🎭

Command Palette

Search for a command to run...

Retour au dossier : Faites entrer HTTP
04
Pièce N°04

Le Formulaire de la Demande

Le client parle. Mais il ne parle pas en criant dans le noir. Il articule une requête HTTP, un document structuré, codé, qui laisse peu de place à l'ambiguïté. C'est le formulaire officiel que toute demande doit remplir pour être entendue par le serveur.

1. L'Anatomie d'une Requête : Trois Parties Indispensables

Une requête HTTP valide est un bloc de texte organisé en trois sections distinctes, séparées par une ligne vide.

a. La Ligne de Requête
C'est la première ligne, le coup de sonnette. Elle contient l'essentiel :

  • La Méthode : L'action souhaitée (GET, POST, etc.).
  • Le Chemin (URI) : L'adresse de la ressource demandée sur le serveur (/index.html, /api/users).
  • La Version du Protocole : HTTP/1.1 ou HTTP/2. Exemple : GET /contact HTTP/1.1

b. Les En-têtes (Headers)
Ce sont les métadonnées, les instructions annexes. Une série de lignes Clé: Valeur qui précisent le contexte. Elles peuvent indiquer :

  • Quel navigateur fait la demande (User-Agent)
  • Quels types de contenu le client accepte (Accept)
  • S'il y a des cookies (Cookie)
  • La taille du corps de la requête (Content-Length)
  • L'origine de la requête (Host: www.monsite.com) Exemple :
Host: www.monapi.com
User-Agent: MonNavigateur/1.0
Accept: application/json

c. Le Corps de la Requête (Body)
Cette section est optionnelle. Elle n'existe que pour certaines méthodes, comme POST ou PUT. C'est ici qu'on place les données à envoyer au serveur : le contenu d'un formulaire, un fichier JSON, une image. Une ligne vide marque la fin des en-têtes et le début du corps.

2. Le Verbe de l'Action : Les Méthodes HTTP

La méthode, c'est le verbe qui donne son sens à la requête. Elle dit ce qu'il faut faire avec la ressource identifiée par l'URL.

  • GET : Le plus courant. "Récupère-moi cette ressource." Il est utilisé pour lire des données, charger une page, une image. Les données sont envoyées dans l'URL (paramètres de requête). Il ne doit pas modifier quoi que ce soit sur le serveur. C'est une opération "safe".

  • POST : "Reçois et traite ces données." Il est utilisé pour envoyer des informations au serveur : soumission d'un formulaire de contact, upload d'un fichier, création d'un nouvel article. Les données sont placées dans le corps de la requête.

  • PUT : "Remplace complètement la ressource à cette URL par celle que je t'envoie." Utilisé pour mettre à jour une entité existante (un profil utilisateur). Idempotent : le faire une fois ou dix fois a le même effet.

  • PATCH : "Applique une mise à jour partielle à la ressource." Plus léger que PUT, il ne modifie que certains champs. Idéal pour des corrections ponctuelles.

  • DELETE : "Supprime la ressource à cette URL."

  • Les autres :

    • HEAD : Comme GET, mais demande seulement les en-têtes de la réponse, pas le corps. Utile pour vérifier si un fichier existe ou sa date de modification.
    • OPTIONS : Demande au serveur quelles méthodes sont autorisées pour une ressource donnée.

3. Comment Passer les Données : Les Deux Voies

a. Les Paramètres de Requête (Query Parameters)
Pour GET principalement, on ajoute les données directement dans l'URL, après un point d'interrogation ?. C'est un ensemble de paires clé=valeur, séparées par &. Exemple : GET /search?q=http&lang=fr HTTP/1.1
Ici, on envoie deux paramètres : q (avec la valeur "http") et lang (avec "fr"). C'est visible, enregistrable dans l'historique, mais limité en taille.

b. Le Corps (Body)
Pour POST, PUT, PATCH, les données voyagent de manière plus discrète et sans limite de taille dans le corps de la requête. Le format est précisé par un en-tête Content-Type :

  • application/x-www-form-urlencoded : Le format classique des formulaires HTML. Les données sont encodées comme dans une URL (nom=Dupont&prenom=Jean).
  • multipart/form-data : Obligatoire pour l'upload de fichiers. Il permet de mélanger des champs texte et des données binaires.
  • application/json : Le standard moderne des APIs. Le corps est un objet JSON structuré et facile à parser. 
    {"username": "jane_doe", "email": "jane@example.com"}
  • text/xml : Moins courant aujourd'hui, pour du XML.

Le serveur regarde l'en-tête Content-Type pour savoir comment décoder le corps qu'il reçoit. Sans cette information, il serait perdu.

Ainsi, chaque requête HTTP est un paquet soigneusement emballé : une intention claire (méthode), une destination précise (URI), des instructions de livraison (en-têtes) et, si nécessaire, un contenu (corps). Le serveur n'a plus qu'à déballer et exécuter.