Les requêtes HTTP expliquées simplement

Sur le Web, les clients, comme votre navigateur, communiquent avec les serveurs Web en utilisant le protocole HTTP. Ce protocole contrôle la façon dont le client formule ses demandes et la façon dont le serveur y répond. Le protocole HTTP connaît différentes méthodes de requête. Il est utile de connaître au moins les plus courantes d’entre elles. Dans cet article, vous apprendrez les détails des méthodes de requête HTTP.

GET est l’ « ancêtre » des requêtes HTTP. Cette méthode de requête existe depuis le début du Web. Elle est utilisée pour demander une ressource, par exemple un fichier HTML, au serveur Web.

Si vous entrez l’URL www.exemple.com dans votre navigateur, celui-ci se connecte au serveur Web et lui envoie la requête GET :

Le fichier index.php dans cet exemple est simplement la page d’accueil ; il est envoyé du serveur au navigateur.

De même, la demande de l’URL www.exemple.com/test.html serait formulée ainsi :

Le serveur renvoie le fichier test.html.

Le serveur envoie le fichier test. La requête GET peut recevoir des informations supplémentaires que le serveur Web doit traiter. Ces paramètres d’URL sont simplement ajoutés à l’URL. La syntaxe est très simple :

• La chaîne de requête est introduite par un « ? » (point d’interrogation).
• Chaque paramètre est nommé, il se compose donc d’un nom et d’une valeur : « Nom=Valeur ».
• Si plusieurs paramètres doivent être inclus, ils sont reliés par un « & ».

Voici un exemple : sur le site Web d’une entreprise de logiciels, « Windows » est saisi comme plateforme et « Office » comme catégorie pour afficher les offres correspondantes du serveur :

Les chaînes Query nécessitent un encodage de caractères spéciaux car de nombreux caractères spéciaux ont une signification particulière. Par exemple, le texte « HTTP Overview » doit être codé comme suit pour être accepté comme chaîne d’interrogation

Si vous souhaitez envoyer de grandes quantités de données, par exemple des images, ou des données confidentielles de formulaires au serveur, la méthode GET n’est pas idéale car toutes les données que vous envoyez sont écrites ouvertement dans la barre d’adresse du navigateur.

Dans ces cas, la méthode POST est la plus adaptée. Cette méthode n’écrit pas les paramètres de l’URL, mais les ajoute à l’en-tête HTTP.

Les requêtes POST sont principalement utilisées pour les formulaires en ligne. Voici un exemple de formulaire qui prend le nom et l’adresse électronique et les envoie au serveur en utilisant POST :

La méthode HEAD est utilisée pour interroger l’en-tête de la réponse, sans que le fichier ne vous soit envoyé immédiatement. C’est utile, par exemple, si des fichiers volumineux doivent être transférés : grâce à la requête HEAD, le client peut d’abord être informé de la taille du fichier et seulement ensuite décider s’il veut recevoir le fichier.

Exemple :

Avec la méthode OPTIONS, le client peut demander quelles méthodes le serveur supporte pour le fichier en question.

Dans le champ « allow », nous apprenons que le serveur prend en charge les méthodes OPTIONS, GET, HEAD et POST. Dans le champ « content-length », le chiffre 0 nous indique qu’aucun fichier n’a été transféré, seulement l’en-tête.

La méthode TRACE peut être utilisée pour tracer le chemin qu’une requête HTTP emprunte jusqu’au serveur puis jusqu’au client. Vous pouvez utiliser la commande tracert de Windows pour tracer vous-même cet itinéraire. Pour ce faire, entrez la commande suivante dans la ligne de commande (cmd.exe) :

Certaines méthodes ne sont applicables que dans le cadre de configurations spécifiques. Il s’agit notamment de la méthode CONNECT, qui établit une connexion directe et protégée via un proxy (tunneling), et de diverses méthodes en rapport avec WebDAV : PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK.

PUT, PATCH et DELETE sont utilisés pour enregistrer, modifier ou supprimer des fichiers sur le serveur. Dans la programmation normale d’un site Web, ces méthodes ne jouent pratiquement aucun rôle, car elles sont bloquées par les serveurs pour des raisons de sécurité. Ils trouvent leur application dans le contexte de WebDAV et en relation avec REST-API.