La nouvelle méthode HTTP QUERY expliquée

Méthode HTTP QUERY : la fin du POST déguisé en GET ?

L'IETF a publié le mois dernier une RFC qui introduit cette méthode au protocole HTTP. Elle règle le problème des GET complexes avec payload, ceux qui forçaient les développeurs à passer par du POST en offrant une méthode sûre et normalisée.

Quel problème résout la méthode HTTP QUERY ?

Imaginez que vous ayez /clients qui expose une liste de clients. Pour récupérer toute la liste, rien de plus simple, on peut faire GET /clients. Pour paginer les résultats, il est encore possible de le faire à travers des paramètres d'URLUniform Ressource Locator avec GET /clients?page=1&size=50

Mais dès qu'on veut des requêtes HTTP complexes, tout s'effondre! Impossible de l'envoyer dans l'URL (par exemple car la requête serait trop lourde), obligé donc de le stocker dans le payload de la requête. Seul problème avec cette méthode : la RFC demande à ce qu'il n'y ait pas d'envoi de payload dans une requête GET. Qu'est-ce qu'on faisait pour ça jusqu'à maintenant? Un endpoint séparé, commme /clients/search qui s'appelle en POST et qui pourra accepter un payload plus conséquent. Revenons cependant aux inconvénients du POST dans la sémantique HTTP : le POST n'est pas sensé être idempotent, et ne permet donc pas de mettre en cache la réponse fournie par le serveur.

La solution à tout ça : la méthode Query

La RFC 10008, en préparation depuis 2021, vient d'être publiée. Elle introduit une méthode pensée pour être sûre et idempotente :

• Sûre : la méthode est en lecture seule. Le client ne doit jamais s'attendre à ce que son appel modifie l'état du serveur.
• Idempotente : la méthode retourne toujours le même résultat, quel que soit le nombre d'appels. GET est idempotent, POST ne l'est pas, puisqu'on est censé créer une entité différente à chaque appel.

L'idée derrière la méthode HTTP QUERY : envoyer l'équivalent d'un GET avec un payload complexe, tout en conservant la mise en cache sur la lecture. Grâce à ces deux propriétés, la réponse devient cachable, un avantage non négligeable pour la performance de vos applications.

Comment implémenter la méthode HTTP Query dans vos projets

Le problème des nouvelles méthodes HTTP, c'est quelles mettent quelques temps à se répandre sur toutes nos plateformes, et c'est aussi le cas pour QUERY.

En JS, sur vos sites, il vous est possible pour le moment d'utiliser une méthode personalisée, comme dans cet exemple de code :

const response = await fetch("/clients", {
  method: "QUERY", // on fait l'appel avec notre méthode personnalisée
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    filter: { status: "active", country: "FR" },
    sort: "name",
    page: 1,
  }),
});

Cependant, vous n'aurez pas la mise en cache fournie par le navigateur (car cette mise en cache ne peut pas être forcée manuellement) sur ces requêtes.

Du côté des framework backend, Spring Boot est actuellement en train d'ajouter le support pour la méthode à travers cette PR .NET à déjà ajouté le support de la méthode QUERY avec .NET 10!

Nouvelle méthode HTTP : Query, notre avis !

Le déploiement le plus critique se joue côté backend, là où il est essentiel que les navigateurs ajoutent les en-têtes permettant la mise en cache. Côté frontend, vous pourrez "juste" utiliser une méthode personnalisée en attendant que les navigateurs gèrent cette mise en cache de manière transparente.

Un conseil : suivez de près le déploiement de la méthode HTTP QUERY dans vos frameworks backend préférés. Et saluons au passage l'IETF, qui n'aura mis que 5 ans de discussions, après 20 ans à vivre avec le même problème, pour sortir une nouvelle méthode HTTP !