RFC 10008 : la méthode HTTP QUERY met fin au dilemme GET ou POST

En juin 2026, l'Internet Engineering Task Force (IETF) a publié le RFC 10008, qui élève la méthode HTTP QUERY au rang de standard officiel (Standards Track). Ce texte, signé par Julian Reschke (greenbytes), James M. Snell (Cloudflare) et Mark Bishop (Akamai), répond à un problème que tout développeur backend a croisé un jour : comment interroger une ressource avec des critères de recherche trop volumineux ou trop structurés pour tenir dans une URL, sans perdre les garanties de sécurité et de cache qu'offre GET.

Voici ce que change concrètement ce RFC pour vos API, et dans quels cas vous devriez envisager de migrer vos endpoints de recherche vers cette nouvelle méthode.

Le problème que QUERY vient résoudre

Petit rappel pour ceux qui découvrent le sujet. Le pattern historique pour une recherche HTTP consiste à encoder les paramètres directement dans l'URL, via GET :

GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
Host: example.org

Ce pattern devient problématique dès que les données à transmettre sont trop volumineuses ou trop structurées. Le RFC 10008 liste quatre limites concrètes : les limites de taille d'une URI ne sont pas connues à l'avance, car une requête traverse souvent des systèmes non coordonnés (le RFC 9110 recommande de supporter au moins 8000 octets, sans garantie au-delà) ; encoder certains types de données dans une URI valide génère un surcoût inutile ; les URI de requête sont plus souvent journalisées que le contenu de la requête, et peuvent se retrouver dans des favoris ; enfin, chaque combinaison de paramètres est traitée comme une ressource distincte, ce qui n'a pas toujours de sens.

Beaucoup d'équipes contournent le problème avec POST : le contenu de la requête part dans le corps plutôt que dans l'URL. Le souci, c'est qu'un POST n'offre par définition aucune garantie de sécurité ni d'idempotence pour les intermédiaires (caches, proxies, CDN). Impossible de savoir, sans connaître l'implémentation exacte du serveur, qu'il s'agit en réalité d'une simple lecture.

Ce que QUERY change concrètement

La méthode QUERY reprend le principe du POST (contenu dans le corps) tout en étant explicitement sûre et idempotente, comme GET. Le même exemple s'écrit désormais :

QUERY /feed HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded

q=foo&limit=10&sort=-published

Deux garanties changent tout pour un développeur backend ou pour l'équipe qui gère votre infrastructure :

• Sûre. Le client n'attend et ne demande aucun changement d'état côté serveur. Un intermédiaire (CDN, reverse proxy, navigateur) peut donc mettre le résultat en cache en toute confiance.
• Idempotente. La requête peut être rejouée ou relancée automatiquement, par exemple après une coupure réseau, sans risque de dupliquer un effet de bord puisqu'il n'y en a pas.

Le RFC impose aussi une discipline stricte sur l'en-tête Content-Type, qui devient obligatoire. Le serveur doit rejeter la requête si ce champ est absent ou incohérent avec le contenu réel :

• Pas de Content-Type du tout : 400 (Bad Request).
• Content-Type présent mais non supporté par la ressource : 415 (Unsupported Media Type). Le serveur peut alors indiquer les types acceptés via l'en-tête de réponse Accept-Query.
• Content-Type incohérent avec le corps réel : 400. Le serveur n'a pas le droit de deviner le type en inspectant le contenu.
• Type reconnu et cohérent, mais requête inexploitable sur le fond : 422 (Unprocessable Content). Le RFC donne un exemple parlant : une requête SQL syntaxiquement correcte mais qui vise une table qui n'existe pas.

Autre nouveauté utile : le serveur peut désormais attribuer une URI à la requête elle-même (en-tête Location) ou au résultat spécifique d'une requête (en-tête Content-Location), pour la retrouver plus tard via un simple GET.

Le RFC résume les trois méthodes dans un tableau qui mérite d'être gardé sous la main :

Quand remplacer vos POST de recherche par QUERY

Ce standard vise en priorité les endpoints de recherche à critères multiples : recherche e-commerce avec filtres combinés (prix, catégorie, disponibilité, localisation), tableaux de bord d'administration avec recherche avancée, API de recherche full-text avec un corps JSON structuré. Autrement dit, tout endpoint que vous avez aujourd'hui implémenté en POST uniquement parce que le corps de la requête ne tenait pas dans une URL.

Le même exemple de recherche, écrit aujourd'hui en POST, devient avec QUERY :

curl -X QUERY https://api.example.com/search -H "Content-Type: application/json" -d '{"q":"ordinateur portable","filters":{"prix_max":800,"disponible":true}}'

Même corps, même structure applicative, mais une sémantique HTTP désormais explicite : un CDN, un reverse proxy ou le navigateur du visiteur peuvent mettre ce résultat en cache et relancer automatiquement la requête en cas de coupure, exactement comme ils le feraient pour un GET.

Attention toutefois : la méthode QUERY vient tout juste d'être standardisée. En juillet 2026, tous les frameworks backend, bibliothèques HTTP clientes, pare-feux applicatifs (WAF) et load balancers ne la reconnaissent pas encore nativement, certains bloquant par défaut les méthodes HTTP non répertoriées. Avant de basculer un endpoint de recherche critique en production, vérifiez le support côté framework (routage explicite de la méthode QUERY), côté CDN et côté WAF, et appuyez-vous sur l'en-tête de réponse Accept-Query pour détecter le support côté serveur.

Notre lecture chez CZSyn

Ce RFC règle un vrai problème de conception que nous croisons régulièrement chez nos clients : des endpoints de recherche bricolés en POST uniquement pour contourner les limites d'URL, avec pour conséquence des caches CDN inopérants et des relances manuelles côté frontend en cas d'échec réseau. La méthode QUERY permet enfin de déclarer sans ambiguïté qu'une recherche, même complexe, reste une lecture sûre et rejouable.

Pour une PME française qui expose une API de recherche (catalogue e-commerce, moteur de recherche interne, agrégateur de contenu), l'intérêt n'est pas immédiat : il faudra attendre que les CDN, WAF et frameworks du marché absorbent ce nouveau standard avant de l'exposer en production sans filet. Mais c'est le bon moment pour commencer à tester en environnement de recherche ou de préproduction, et pour concevoir vos futurs endpoints de recherche directement avec QUERY en tête plutôt que de perpétuer le compromis GET ou POST.

Sources primaires

• IETF, RFC 10008, « The HTTP QUERY Method », juin 2026.
• RFC Editor, page d'information du RFC 10008 (statut, errata).
• IETF, RFC 9110, « HTTP Semantics », référence normative citée par le RFC 10008.