Pendant seize ans, les développeurs qui avaient besoin de poser des questions complexes à un serveur ont dû se contenter d'une solution de contournement. Lorsqu'une charge utile de recherche devenait trop volumineuse pour une URL, ou lorsque des filtres imbriqués et des paramètres sensibles refusaient de tenir dans une chaîne de requête, la seule option pratique était POST. Elle transportait les octets, mais elle mentait sur l'intention. POST signale un changement d'état. L'utiliser pour une opération en lecture seule forçait l'ensemble du chemin réseau — caches, proxys et navigateurs — à traiter une simple consultation comme si elle pouvait modifier une base de données.

Ce compromis a enfin pris fin. En juin 2026, l'IETF a publié la RFC 10008, standardisant formellement la méthode QUERY. Il s'agit de la première nouvelle méthode HTTP depuis l'introduction de PATCH en 2010. QUERY existe spécifiquement pour les requêtes sûres et idempotentes qui ont besoin d'un corps de requête. Elle ne modifie pas l'état du serveur. Répéter la même requête produit le même résultat. Elle est cacheable, ce qui signifie que les intermédiaires peuvent stocker et réutiliser la réponse. Et contrairement à GET, elle permet une charge utile de données, tout comme POST.

Les requêtes GraphQL et les points de terminaison de recherche REST complexes sont les grands gagnants. Vous n'aurez plus à entasser soixante paramètres de requête dans une URL ou à cacher un document de filtre JSON dans un corps POST que les intermédiaires refuseront de mettre en cache. La sémantique est désormais honnête.

Mais une RFC n'est que de l'encre. Entre votre application et vos utilisateurs se trouve une épaisse couche d'infrastructure, et la majeure partie d'entre elle n'a jamais entendu parler de QUERY.

Le problème de la mise en cache n'est pas encore résolu

Avec une requête GET, la mise en cache est simple. La clé de cache est l'URI. Deux utilisateurs accédant à la même URL obtiennent la même réponse stockée, à condition que les en-têtes le permettent.

QUERY brise ce modèle car les paramètres de la requête se trouvent dans le corps. Pour qu'un cache reconnaisse que deux requêtes sont identiques, la clé de cache doit intégrer à la fois l'URI et le contenu du corps. Cette exigence introduit une réelle friction opérationnelle.

Premièrement, les serveurs de bordure et les CDN doivent mettre en mémoire tampon l'intégralité du corps de la requête avant de pouvoir calculer un hachage. Cela consomme de la mémoire et du temps au niveau du nœud de bordure. Deuxièmement, deux requêtes logiquement identiques peuvent ne pas produire les mêmes octets. Un client peut envoyer {"status":"active"} tandis qu'un autre envoie {"status": "active"} avec des espaces blancs ou un ordre de clés différents. À moins que la couche de cache n'analyse, normalise et canonicalise le corps — en triant les clés JSON, en supprimant le formatage insignifiant et en gérant les différences d'encodage — la même question manquera le cache à chaque fois.

Plus important encore, les principaux CDN ne partitionnent pas encore le cache par corps de requête pour QUERY. Cloudflare, par exemple, ne traite pas le corps comme faisant partie de la clé de cache pour cette méthode dans sa forme actuelle. Si vous déployez QUERY en supposant que "cacheable" signifie "mis en cache", vous pourriez rencontrer des erreurs de collision, des échecs de cache universels ou des réponses qui fuient vers des requêtes sans rapport. Tant que votre fournisseur ne publie pas de support explicite, partez du principe que QUERY n'est pas réellement cacheable en production.

Vos outils seront probablement les premiers à le bloquer

Chaque requête HTTP traverse une pile de middleboxes, et la plupart d'entre elles appliquent des règles strictes sur les méthodes autorisées.

Les pare-feu d'applications Web (WAF) et les passerelles d'API reposent souvent sur des listes d'autorisation explicites. Un ensemble de règles typique autorise GET, POST, PUT, DELETE et PATCH. Tout le reste est rejeté ou reçoit une réponse 405 Method Not Allowed. QUERY se heurtera à ces obstacles avant même d'atteindre votre code applicatif.

Les moteurs de règles de sécurité ajoutent un autre obstacle. Certains systèmes de détection d'intrusion partent du principe qu'une requête transportant un corps