Résumé

  • QUERY transporte une expression dans le contenu de la requête tout en étant enregistrée comme méthode sûre et idempotente. Cette qualification oblige l'application ; elle ne démontre pas qu'un traitement donné est sans effet métier.
  • Le cache doit intégrer le contenu et ses métadonnées à la clé. Relances, redirections, validateurs, Accept-Query et URI équivalente répartissent des pouvoirs distincts entre client, intermédiaire et origine.

Le cas d'usage paraît banal : interroger un catalogue avec une expression longue, des filtres imbriqués et une projection précise. L'inscrire dans l'URI d'un GET expose la demande aux limites et aux journaux centrés sur l'adresse. L'envoyer par POST résout le transport, mais un échec de connexion laisse le client sans présomption générale sur la possibilité de recommencer.

Le RFC 10008, publié en juin 2026 comme Proposed Standard, crée QUERY pour cette zone intermédiaire. Le contenu est obligatoire ; son type de média décrit le langage de requête ; le contenu et les métadonnées pertinentes forment ensemble la question posée à la ressource cible. L'IANA inscrit désormais QUERY comme sûre et idempotente, et Accept-Query comme champ HTTP permanent.

Ce vocabulaire a une portée juridique au sein du protocole. « Sûre » signifie que l'intention demandée est la consultation, non une modification métier. « Idempotente » signifie que répéter une demande identique produit le même effet voulu qu'une seule exécution, sans promettre des octets de réponse identiques. Une rotation de secret, une réservation, un débit de quota ou une validation ne devient pas licite sous QUERY parce que le code est déterministe.

La propriété de méthode autorise d'autres acteurs à se fier

Une bibliothèque de transport peut relancer une méthode idempotente après une coupure dont elle ignore le point exact. Un agent peut automatiser plus volontiers une méthode sûre. Un cache peut traiter une méthode qu'il comprend selon ses règles propres. L'origine qui expose QUERY consent donc à ces formes de confiance.

La preuve ne peut pas s'arrêter au routeur ou à la documentation d'API. Il faut relier la méthode, l'empreinte exacte du contenu et de son type, le contexte d'identité, l'entrée dans l'application, les effets observés et la représentation rendue. Lors d'une relance, la trace doit répondre à deux questions : la première tentative a-t-elle été exécutée et la seconde a-t-elle créé un effet interdit ?

La journalisation technique peut rester un effet accessoire compatible avec une méthode sûre. En revanche, facturer l'analyse, consommer un jeton à usage unique ou avancer un curseur métier parce que l'utilisateur l'a demandé fait partie de la sémantique. C'est cette frontière, et non le verbe du contrôleur, qui décide de la conformité.

Pour le cache, le contenu fait partie de l'identité

Le RFC 10008 impose d'inclure le contenu de QUERY et ses métadonnées pertinentes dans la clé de cache. Même méthode, même URI, deux corps différents : ce sont deux demandes différentes. Une infrastructure qui n'indexe que l'URI peut livrer le résultat d'un filtre à un autre.

Cette règle oblige parfois le cache à lire tout le contenu avant de calculer sa clé. Taille maximale, mémoire, temporisation, flux et contre-pression entrent alors dans le contrat de production. L'avantage d'une URI plus courte peut déplacer le coût vers une couche qui n'avait pas l'habitude de retenir le corps d'une lecture.

Un cache conscient du type de média peut normaliser des différences sans portée sémantique. Mais cette faculté est une délégation de sens. Supprimer des espaces convenus est une chose ; trier un tableau dont l'ordre compte en est une autre. Une collision de normalisation répond à la mauvaise question sans que l'origine puisse la corriger. no-transform reste un signal de contrôle HTTP, non une attestation d'audit garantissant qu'aucune représentation de clé n'a été transformée.

Le corpus d'essai doit donc couvrir les deux risques : plusieurs écritures d'une même expression et des expressions distinctes d'apparence voisine. Nombres, Unicode, doublons, valeurs par défaut, encodage du contenu, signatures et partition de sécurité font partie de la comparaison. Tant qu'une règle canonique n'est pas partagée par tous les parseurs concernés, la séparation stricte est plus sûre que l'intuition.

Donner une URI au résultat crée une nouvelle institution

Une ressource équivalente dérive de la ressource cible, du contenu QUERY et de ses métadonnées. L'origine peut lui attribuer une URI afin qu'un GET ultérieur retrouve le résultat. Une expression éphémère devient ainsi un nom réutilisable, partageable ou mémorisable.

Il faut préserver la différence entre Location et Content-Location. Dans une réponse QUERY réussie, Location peut désigner une ressource équivalente ou une ressource de requête à récupérer par GET. Content-Location rattache la représentation renvoyée à une URI selon la sémantique HTTP. Les réduire à un unique « canonical URL » efface la nature de l'engagement pris par le serveur.

Le nom peut aussi trahir la question. Replacer le filtre, l'identifiant de compte ou le diagnostic dans l'URI générée réintroduit ces données dans l'historique, les journaux et les références. Un identifiant opaque limite cette fuite, mais crée des exigences de durée, d'autorisation et de révocation. Une adresse stable peut survivre au contexte qui avait autorisé la première évaluation.

Le RFC 3986 normalise la syntaxe de l'identifiant. Il ne décide ni de sa confidentialité, ni de sa durée, ni de sa transférabilité. Ces choix appartiennent à l'origine, qui doit en assumer les conséquences en dehors de l'échange initial.

Une redirection décide du devenir de la méthode

Pour 301, 302, 307 et 308, QUERY est conservée. Les exceptions historiques qui peuvent transformer POST en GET ne s'appliquent pas. Le statut 303 exprime, lui, le passage à GET. Ce détail détermine si le contenu est renvoyé à une nouvelle cible ou si le client suit l'adresse d'une ressource.

Un proxy qui transforme QUERY en GET par habitude peut perdre le contenu ou tenter de le reconstruire dans l'URI. Un autre qui la transforme en POST retire la promesse sur laquelle le client fondait une relance. Chaque statut doit être exercé, en particulier lorsque l'autorité change et que justificatifs et contenu ne suivent pas les mêmes règles.

Pour une QUERY conditionnelle, les validateurs portent sur la représentation qu'un GET de la ressource équivalente aurait sélectionnée. Le contexte d'autorisation et la négociation de contenu restent donc décisifs. Une empreinte du corps de requête n'est pas à elle seule un validateur de la représentation.

Accept-Query est une capacité située dans le temps

Accept-Query publie les types de média acceptés sous forme de List conforme au RFC 9651. Son signal vaut pour le même chemin en faisant abstraction de la partie query de l'URI ; parmi plusieurs observations, la valeur fraîche la plus récente prévaut.

Ce n'est ni une promesse mondiale ni une preuve que chaque expression est valide. Durant un déploiement progressif, deux nœuds peuvent annoncer des listes différentes. La supervision doit conserver la réponse source, sa fraîcheur, le chemin et la version du nœud.

Côté navigateur, QUERY ne figure pas parmi les méthodes CORS simples du Fetch Standard. Un appel interorigine exige donc une requête préliminaire. L'origine peut implémenter QUERY parfaitement et rester inaccessible si passerelle, politique CORS ou produit de sécurité refuse ce nouveau verbe.

Hors de l'URI ne signifie pas hors de vue

Le contenu évite certains journaux fondés sur l'URI et les liens copiés. Il traverse néanmoins le client, les outils du navigateur, la terminaison TLS, les passerelles, les caches, les traces et le serveur. Une relance le transmet de nouveau ; une redirection peut le déplacer ; une URI équivalente mal conçue peut l'exposer durablement.

La distinction de Lu Heng entre souveraineté formelle et réalité pratique des données devient très concrète. L'origine maîtrise formellement le langage accepté. La garde effective appartient aussi aux intermédiaires qui voient le contenu ou son empreinte.

Son principe de spécification initiale minimale et de décision locale éclaire le partage : la norme fixe un verbe, ses propriétés, le cache, les redirections et l'annonce de capacité. L'origine choisit les langages et les noms ; le client choisit l'émission et la relance ; le cache choisit seulement lorsqu'il sait préserver l'identité.

Enfin, la primauté du code exécuté impose de vérifier les résultats. Le RFC prouve l'attente commune. Les traces prouvent — ou démentent — l'absence d'effet, la complétude de la clé et la protection du contenu.