Méthode HTTP QUERY : guide développeur RFC 10008 (2026)

Le 15 juin 2026, l'IETF a publié la RFC 10008, qui définit la méthode HTTP QUERY — la première nouvelle méthode HTTP depuis PATCH en 2010. Seize ans, c'est une éternité dans le développement web, et QUERY n'est pas sortie de nulle part : l'idée remonte à un brouillon de 2015, relancée au HTTP Workshop de 2019, adoptée par le groupe de travail httpbis en 2021 (d'abord sous le nom SEARCH), avant d'atteindre enfin la publication en standard cet été.

QUERY résout un problème que tous les développeurs backend contournent depuis des années : il n'existait aucune méthode HTTP pour une requête en lecture seule qui transporte un corps. Dans ce guide, nous couvrons ce qu'est QUERY, pourquoi elle compte, comment fonctionne la mise en cache, l'état du support dans les frameworks aujourd'hui, et quand l'adopter concrètement.

Le problème : GET contre POST pour les requêtes complexes

Prenons une recherche de produits classique. L'approche RESTful « correcte » utilise GET avec des paramètres d'URL :

GET /products?category=shoes&maxPrice=100&sort=price_asc HTTP/1.1
Host: shop.example

Cela fonctionne jusqu'à ce que vos filtres grossissent. Recherche à facettes, conditions imbriquées, requêtes géographiques, ou tout ce qui ressemble à un vrai langage de requête produit rapidement des URL pénibles à construire, qui butent sur les limites de longueur des proxys et serveurs, et qui divulguent les détails de la requête dans les journaux d'accès et l'historique du navigateur.

Alors les développeurs se rabattent sur POST :

POST /api/search HTTP/1.1
Content-Type: application/json
 
{ "category": "shoes", "maxPrice": 100, "sort": "price_asc" }

Cela fonctionne, mais la sémantique est fausse. POST indique à chaque intermédiaire — caches, proxys, logique de réessai, outils de supervision — que cette requête peut modifier l'état. Conséquences :

• Pas de mise en cache. Les réponses à POST ne sont pas réutilisables par les caches partagés en pratique.
• Pas de réessai sûr. Un client qui perd la connexion ne peut pas renvoyer un POST aveuglément : il risquerait de dupliquer un effet de bord. Votre endpoint de recherche n'a aucun effet de bord, mais rien dans le protocole ne le déclare.
• Intention opaque. POST /search, POST /reports/run et POST /orders sont identiques au niveau du protocole, alors qu'un seul d'entre eux crée réellement quelque chose.

Chaque endpoint GraphQL, chaque appel de recherche Elasticsearch, chaque API de reporting a vécu avec ce décalage pendant une décennie.

Ce qu'apporte QUERY

La RFC 10008 définit QUERY comme une méthode qui demande au serveur « de traiter le contenu joint de manière sûre et idempotente, puis de répondre avec le résultat de ce traitement ». Trois propriétés la distinguent de tout ce qui existait :

Une requête QUERY ressemble à un POST mais se comporte comme un GET. Voici l'exemple canonique de la RFC :

QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json
 
select=surname,givenname,email&limit=10&match=%22email=*@example.*%22

HTTP/1.1 200 OK
Content-Type: application/json
 
[
  { "surname": "Smith", "givenname": "John", "email": "smith@example.org" },
  { "surname": "Jones", "givenname": "Sally", "email": "sally.jones@example.com" }
]

Le corps peut adopter n'importe quel type de média — formulaire encodé, JSON, GraphQL, DSL maison. Le serveur annonce ce qu'il accepte via le nouvel en-tête de réponse Accept-Query, qui liste les types de média supportés en syntaxe Structured Fields.

Comme QUERY est idempotente, les clients et bibliothèques peuvent réessayer automatiquement une requête échouée après une coupure de connexion — chose strictement interdite avec POST. Comme elle est sûre, les outils de supervision et de sécurité peuvent la traiter comme du trafic en lecture seule.

La mise en cache : la partie intéressante

Les réponses GET sont mises en cache par URL. Les réponses QUERY le sont aussi, mais la clé de cache doit incorporer le contenu de la requête, pas seulement l'URI. Deux requêtes QUERY vers /search avec des corps JSON différents constituent deux entrées de cache distinctes.

La RFC va plus loin et autorise les caches à normaliser le contenu de la requête avant de calculer la clé — en gommant les différences d'encodage, d'espaces ou d'ordre des clés JSON. Bien fait, deux requêtes équivalentes formatées différemment touchent la même entrée de cache. Mal fait, un bug de normalisation peut servir la mauvaise réponse à la mauvaise requête, ce que la spécification signale explicitement comme un enjeu de sécurité.

Un dernier détail élégant : un serveur peut répondre à QUERY par 303 See Other, pointant le client vers une URI représentant le résultat de la requête. Le client émet alors un simple GET — transformant une requête coûteuse avec corps en une ressource partageable et cachable de manière conventionnelle.

Support des frameworks et de l'écosystème en 2026

L'adoption est précoce mais réelle :

• .NET 10 livre un support natif des deux côtés. Le client expose HttpMethod.Query, et ASP.NET Core 10 fournit la constante HttpMethods.Query ainsi que HttpMethods.IsQuery() :

// Client
using var request = new HttpRequestMessage(HttpMethod.Query, "https://api.example/products/search")
{
    Content = JsonContent.Create(filter)
};
 
// Serveur (ASP.NET Core 10)
app.MapMethods("/products/search", new[] { HttpMethods.Query }, async (HttpRequest req) =>
{
    var filter = await req.ReadFromJsonAsync<ProductFilter>();
    return Results.Ok(await search.RunAsync(filter));
});

Les aides comme MapQuery() et l'attribut [HttpQuery] ont été retirées de cette version ; les équipes écrivent pour l'instant leurs propres extensions.

• Node.js et autres : QUERY n'étant syntaxiquement qu'un jeton de méthode supplémentaire, la plupart des serveurs HTTP la laissent passer ; le support au niveau des routeurs arrive progressivement dans les frameworks.
• Navigateurs : fetch et XHR ne peuvent pas encore envoyer QUERY, et QUERY ne figure pas dans la liste des méthodes CORS autorisées d'office : tout usage cross-origin déclenche un prévol. Pour l'instant, QUERY brille dans la communication de serveur à serveur.
• CDN et proxys : malgré la participation d'ingénieurs de Cloudflare et Akamai à la rédaction de la RFC, la mise en cache des réponses QUERY à grande échelle en périphérie n'est pas encore fiable.
• OpenAPI : la version 3.1 ne permet pas de décrire les endpoints QUERY ; ASP.NET Core les exclut simplement des documents générés.

Faut-il adopter QUERY maintenant ?

Une grille de décision pragmatique :

Adoptez dès maintenant si vous contrôlez le client et le serveur — microservices internes, couches backend-for-frontend, API de données derrière votre propre passerelle. Vous gagnez gratuitement une sémantique honnête, des réessais automatiques sûrs et une mise en cache compatible avec l'avenir.

Attendez si vos consommateurs sont des navigateurs, des intégrateurs tiers utilisant des SDK générés depuis OpenAPI, ou si vous dépendez aujourd'hui du cache en périphérie pour vos résultats de requête.

Conseil de conception : exposez QUERY à côté d'un POST de repli sur la même route pendant la transition, et annoncez le support via Accept-Query. Les clients qui comprennent QUERY profitent de la meilleure sémantique ; les anciens ne perdent rien.

Chez Noqta, nous voyons QUERY comme un choix naturel pour les endpoints de recherche et de reporting dans les architectures API-first que nous construisons — en particulier dans les pipelines d'agents IA, où les agents qui appellent des outils via HTTP bénéficient énormément de requêtes déclarées sûres et réessayables au niveau du protocole.

Conclusion

QUERY comble une lacune présente depuis HTTP/1.1 : les requêtes orientées lecture avec de vraies charges utiles n'ont plus besoin de se déguiser en écritures. La méthode est standardisée, .NET 10 la livre déjà, et le reste de l'écosystème suit. Inutile de réécrire vos API demain — mais la prochaine fois que vous concevrez un endpoint de recherche et ressentirez cette gêne familière face à POST /search, sachez que le protocole a enfin une meilleure réponse.

Seize ans entre deux nouvelles méthodes : celle-ci valait l'attente.