Le mois de juin 2026 restera un moment historique de l’informatique.
Bon, ok, ma compagne en a eu un peu rien à faire quand je lui ai expliqué et je ne raconterai certainement pas ça à mes petits enfants. Mais tout de même, ça n’est pas tous les jours que les normes concernant le HTTP évoluent à ce point!
En effet, le 15 juin dernier, le RFC 10008 a officialisé la méthode QUERY. La dernière fois qu’on a vu un nouveau verbe HTTP, c’était en 2010 avec le PATCH!
Chercher sans créer
Aujourd’hui, pour faire une requête sur une ressource, un schema classique est d’utiliser la méthode GET et de compléter l’URI par des éléments de requête (query params):
GET /articles?q=foo&limit=10&sort=published&direction=asc
Une problématique classique se rencontre lorsque l’ensemble des éléments URI+requête atteint une longueur proche de 2000 caractères.
Jusque maintenant, nous n’étions pas vraiment équipés pour gérer ce cas avec GET puisque cette méthode accepte un corps (body), mais est supporté de façon incohérente selon les clients/serveurs/proxys.
Nous changeons donc de méthode et utilisons POST qui va accepter un corps dont la taille sera plus importante, mais qui n’a pas été conçu pour cela.
Le problème avec POST
POST est normalement destiné à engendrer des effets de bords directement sur la resource visée par la requête, la création notamment.
On dit que la méthode n’est ni safe, ni idempotente.
Safe : Ne provoque pas d’effet de bord voulu ou attendu sur la resource. Peut provoquer néanmoins la création de resources temporaires, la création de statistiques, etc…
Le fait que GET soit considérée comme safe permet de garantir qu’on consulte la donnée sans impact.
Idempotent : le fait d’exécuter N fois la même requête produit le même effet sur l’état du serveur qu’une seule exécution. Attention : ça ne veut pas dire que la réponse est identique à chaque fois (elle peut changer si les données sous-jacentes évoluent) — ça veut dire que l’état du serveur après 1 appel est le même qu’après 10 appels.
POST n’est pas, par définition, idempotente: le but est justement que l’état du serveur change à chaque appel. Soumettre un formulaire de paiement 2 fois = 2 paiements!
Ce qu’apporte QUERY
Cette mise à jour de la norme entérine ce qui était jusque là du domaine de l’implicite. “cette API POST est en fait juste une recherche, promis”
En déclarant Query safe : un client, un proxy ou un crawler peut appeler sans se soucier de « casser » quelque chose. C’est ce qui permet par exemple à Google de crawler des GET sans crainte.
Et idempotente : permet les retries automatiques. Si une connexion tombe après l’envoi d’une requête QUERY mais avant réception de la réponse, le client peut renvoyer la requête sans risque de double effet — contrairement à un POST, où renvoyer aveuglément pourrait dupliquer une action
Ainsi, cela débloque directement le cache et les retries automatiques — deux choses impossibles à faire de façon générique avec POST, même si le POST en question est en pratique un simple GET déguisé.
Points techniques clés
- Content-Type obligatoire : le serveur doit rejeter la requête si le type de contenu est absent ou incohérent avec le corps envoyé.
- Ressource équivalente : le serveur peut assigner une URI au résultat (
Content-Location) ou à la requête elle-même (Location), pour permettre ensuite un simple GET. - En-tête
Accept-Query: permet à une ressource d’annoncer les formats de requête qu’elle accepte (JSONPath, SQL, XSLT…), par exemple :Accept-Query: "application/jsonpath", application/sql. - Cache : la clé de cache doit intégrer le corps de la requête entier, pas seulement l’URI — ce qui rend le caching plus complexe qu’avec
GET - CORS : QUERY n’étant pas une méthode « safelisted » par CORS, elle déclenche une requête preflight.
Je suis sûr que bon nombres d’entre vous y verrons une solution à une problématique concrète rencontrée lors de la conception d’API REST. Il va cependant falloir être patients le temps que cette nouvelle norme soit implémentée par tous les systèmes dont nous dépendons aujourd’hui.
En attendant, on reste sur ses appuis pour les prochains entretiens tech, qui seront à coup sûr l’occasion de se voir poser des questions sur ce nouveau verbe QUERY!
