HTTP QUERY : la méthode qui manquait entre GET et POST

Après plus de quinze ans de compromis architecturaux, l'IETF fait enfin un pas formel pour combler l'une des lacunes historiques de HTTP : la gestion sécurisée et efficace des recherches complexes.

Avec l'introduction de la nouvelle méthode HTTP QUERY, les requêtes et filtres complexes ne devront plus être entassés dans l'URL ni transmis via une méthode non safe comme POST.

HTTP QUERY, une nouvelle méthode pour l'architecture REST

La méthode HTTP QUERY est le premier standard approuvé par l'IETF depuis PATCH, introduit en 2010. Bien qu'elle soit encore loin d'être largement implémentée, la méthode QUERY promet de résoudre l'un des plus anciens dilemmes de l'architecture REST : comment envoyer des recherches ou des filtres complexes sans enfreindre les règles des standards HTTP.

Jusqu'à présent, les recherches avancées devaient être gérées à l'aide de compromis : ni GET ni POST ne constituent, en effet, des solutions idéales.

La méthode GET prévoit que l'envoi des données se fasse via des paramètres dans l'URL (qui présente également des limites de longueur). Cependant, l'insertion des paramètres de recherche dans l'URL peut exposer des données sensibles dans les journaux des serveurs : filtrer un nom et un prénom spécifiques, par exemple, signifie les rendre visibles dans les logs. Le fait de devoir utiliser l'URL rend également impossible l'exécution de requêtes complexes, telles que des requêtes SQL ou des recherches avec des filtres avancés.

POST, en revanche, résout les problèmes d'espace en plaçant la requête dans le body, mais ce n'est pas une méthode safe. POST est conçu pour créer ou modifier des données, c'est-à-dire pour altérer les données sur le serveur. Il est donc considéré comme non idempotent : envoyer plusieurs fois la même requête en utilisant POST ne produit pas toujours le même résultat (comme c'est le cas, par exemple, avec GET ou PUT).

Les caractéristiques de la méthode QUERY

La nouvelle méthode HTTP QUERY résout le problème en combinant deux caractéristiques essentielles : premièrement, elle envoie les paramètres dans le body de la requête sans les exposer dans l'URL, comme POST ; deuxièmement, il s'agit d'une méthode idempotente et cacheable, comme GET.

En résumé, la méthode QUERY :

• Envoie les données dans le body : elle peut donc contenir du JSON, du GraphQL, une syntaxe de type SQL ou des filtres complexes (sans les limites d'espace des query strings), tout en conservant une URL propre ;
• Est safe : elle garantit au serveur et aux CDN que l'opération est en lecture seule et ne modifiera pas l'état des ressources ;
• Est idempotente : la même requête renvoie le même résultat, permettant aux clients d'effectuer automatiquement de nouvelles tentatives en cas d'erreur réseau ;
• Est mise en cache : les proxies, CDN et navigateurs peuvent stocker la réponse en générant une clé de cache basée sur la combinaison de l'URL et du body.

QUERY, décrit dans la RFC 10008 publiée par l'IETF en juin 2026, résout ainsi une incohérence à laquelle les développeurs sont confrontés depuis des années, en combinant la sécurité et l'idempotence de GET avec la capacité structurelle à transporter un payload très détaillé dans le body de la requête, comme avec POST.

Le Content-Type dans la méthode QUERY

Selon les spécifications définies par la RFC 10008, lorsqu'un body est présent dans une requête QUERY, le Content-Type est également obligatoire. Le body peut en effet contenir des formats complètement différents, mais le serveur et les composants réseau (tels que les proxies et les CDN) doivent savoir exactement comment l'interpréter avant de le traiter ou de le mettre en cache.

Le nouveau standard introduit à cet effet un en-tête de réponse « Accept-Query », qui indique au client quels formats de requête le serveur est capable d'accepter et de traiter dans le body d'une requête.

La RFC 10008 introduit également les messages d'erreur correspondants :

• 400 Bad Request : si le media type est absent ou si le body est syntaxiquement incorrect ;
• 415 Unsupported Media Type : si le format n'est pas pris en charge par l'endpoint ;
• 406 Not Acceptable : si le format demandé dans « Accept » ne peut pas être fourni ;
• 422 Unprocessable Content : si la requête est syntaxiquement valide (par exemple, JSON correct), mais que les données enfreignent les règles métier de l'application et n'ont donc pas de sens logique pour le serveur.

HTTP QUERY : la voie vers l'adoption de la nouvelle méthode

L'adoption généralisée de la méthode QUERY est prévue approximativement entre 2027 et 2028. Avant que le nouveau verbe ne devienne un standard concret dans les opérations quotidiennes, l'ensemble de l'écosystème logiciel devra s'adapter : les navigateurs, CDN et frameworks serveur devront mettre à jour leurs bibliothèques afin de reconnaître et de gérer correctement la nouvelle méthode.

Certaines problématiques potentielles doivent également encore être résolues et nécessiteront une adaptation des systèmes de sécurité réseau :

• Angles morts dans les pare-feu : les pare-feu applicatifs (WAF) traditionnels contrôlent le corps du message uniquement pour les méthodes qui modifient les données (POST, PUT). En considérant QUERY comme une méthode safe en lecture seule, ils risquent d'ignorer le body, laissant passer des attaques telles que les injections SQL ou les attaques XSS ;
• Contournement des contrôles Anti-CSRF : puisque QUERY est classée comme une méthode « safe », les middlewares anti-CSRF l'ignorent par défaut. Si un développeur implémente incorrectement l'endpoint de manière à ce qu'il modifie les données sur le serveur, l'application devient vulnérable aux attaques CSRF ;
• Preflight : QUERY ne fait pas partie des méthodes de base automatiquement autorisées par les navigateurs (safelisted). Les appels provenant de domaines différents nécessiteront toujours une requête préliminaire de contrôle (OPTIONS), ce qui pourrait potentiellement doubler les temps de réseau.

Dans tous les cas, la voie vers l'implémentation de la méthode QUERY est désormais tracée. Désormais, le protocole HTTP permettra d'envoyer des requêtes complexes sans modifier les ressources, en combinant la flexibilité de POST avec les garanties de lecture seule et de reproductibilité de GET.