Comprendre les méthodes des requêtes HTTP

GET, POST, UPDATE, PATCH, quelles différences, pour quelles utilisations ?

Article publié le 17/01/2022, dernière mise à jour le 24/10/2023

Il existe 9 méthodes distinctes parmi lesquelles il faut choisir lorsque l'on décide d'envoyer une requête HTTP à un serveur, mais quelles sont leurs différences, leurs utilisations, leurs fonctionnalités et sont-elles toutes utiles ?

Nous allons découvrir cela ensemble !

Dans cet article, j'évoque le concept d'idempotence, si vous n'êtes pas familier avec ce dernier, je vous invite à lire mon article qui y est consacré !

Les 9 méthodes HTTP

GET

Comme son nom l'indique, GET est une méthode pour récupérer une ressource/information. C'est la plus simple des méthodes, elle ne doit pas contenir de corps "body", mais la réponse, elle, en contient généralement un.

Peut-être mis en cache, et doit être idempotente.

POST

La méthode POST sert à créer une ressource. Les données pourront être présentes dans les paramètres de l'URL, ou dans le corps de la requête.

À noter que le succès d'une requête POST génèrera souvent une réponse 201 (Created), au lieu de la traditionnelle 200 (Success).

Pas de cache, et en général non-idempotente (sauf contraintre d'unicité dans les ressources à créer)

PUT

Les requêtes PUT sont très similaires au requêtes POST, mais pour mettre à jour une ressource complète, au lieu de créer cette dernière de 0.

Les vraies différences avec le POST sont que le status de retour est 200, et que l'opération doit être idempotente.

Pas de cache, idempotente.

PATCH

Même utilisation que pour le PUT, mais PATCH est une sémantique particulière pour les mises à jour partielles seulement, et potentiellement non-idempotentes.

On peut retrouver des cas d'usage dans l'ajout d'une ressource à une liste existente par exemple. Le PUT réinitialiserait la liste en entière (avec ou sans objets à l'intérieur), tandis que le PATCH ajouterai un objet.

Pas de cache, pas forcément idempotente.

DELETE

Même chose que le PUT, mais pour supprimer une entité, et sans corps dans la requête (toutes les informations doivent être passées dans les en-têtes ou l'URI).

La réponse peut néanmoins contenir un corps, avec la ressource supprimée par exemple.

Pas de cache, pas de corps (body), idempotente

OPTIONS

Une requête OPTIONS est ce qu'on appelle une "pre-flight request".

C'est elle qui permet au client de s'assurer que la future requête qu'il s'apprète à envoyer répond aux contraintes posées par le serveur (type de contenu disponible, droits d'accès,...). Elle est (souvent) envoyée automatiquement par le client avant une requête qui contient un corps (body) comme POST, UPDATE et DELETE.

Ne doit pas être mise en cache, même si elle est idempotente.

HEAD

On utilise la méthode GET pour récupérer les données "brutes" liées à une url, tandis que l'on va utiliser la méthode HEAD pour récupérer cette fois les "méta-données" liées à la ressource ou au fichier.

Cela va par exemple servir à vérifier si un lien est toujours valide, ou à récupérer le format/poids d'un fichier que l'on souhaiterai télécharger plus tard.

HEAD peut être mis dans dans le cache, et ni la requête, ni la réponse ne doit contenir de corps (body), tout passe par les en-têtes.

TRACE

Cette méthode est exclusivement réservé au debugging du serveur web, son unique utilité est de vérifier si les requêtes sont bien reçues et les réponses bien envoyées.

Dans le fonctionnement normal, chaque message reçu est simplement renvoyé tel-quel, avec les en-têtes:

  • Content-Type: message/http
  • Via: Trace de la route qu'a suivi la requêtes (serveur, proxy,...)

TRACE = Pas de cache, n'est pas utilisé dans les cas d'usages classiques du développement web

CONNECT

Pas vraiment utilisé comme une méthode HTTP classique, CONNECT permet d'utiliser un proxy HTTP comme un tunnel (TCP par exemple).

Pour aller plus loin

Toutes ces méthodes sont documentées dans la section n°9 de la RFC décrivant le fonctionnement du protocole HTTP 1.1, pour en svoir plus, je vous invite à aller lire cette documentation, accessible ici : https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Dans la série sur le HTTP, je vous invite à lire mon article sur les principaux code de réponse et leurs significations


Jakob Søby sur Unsplash

Vous avez terminé l'article ?

Commentaires (0)

pour laisser un commentaire

Aucun commentaire pour l'instant