Résumé

  • Pour la RFC 9110, le jeton de méthode est la principale source de sémantique d’une requête : il expose le but du client, tandis que chaque ressource décide séparément si cette méthode est comprise, mise en œuvre et admise.
  • Safe qualifie l’intention demandée, non l’absence de tout effet de bord. Idempotent qualifie l’effet voulu de répétitions identiques, non l’identité des réponses, des journaux ou de l’état complet du monde.
  • Toute opération sensible doit joindre méthode, cible, principal authentifié, politique d’autorisation, précondition, incertitude sur la première tentative, preuve d’idempotence applicative, reprise, réponse, état final et effets annexes.

Un mot de quatre ou six lettres peut traverser un écosystème que ses auteurs ne connaissent pas. Le client l’émet, un proxy le relaie, une passerelle le classe, un cache l’interprète et un serveur l’applique à une ressource. C’est la puissance de l’interface uniforme : un minimum de sens reste visible sans ouvrir l’application.

La même puissance encourage un raccourci dangereux. Si la méthode est connue, certains en déduisent que l’action est permise. Si elle est dite sûre, ils concluent qu’elle ne produit rien. Si elle est idempotente, ils autorisent des reprises sans limite. Or le standard ne confond aucune de ces propositions.

Le verbe commun ne remplace pas la décision locale

La RFC 9110 définit le jeton de méthode comme l’indication du but poursuivi par le client et du résultat qu’il considère comme un succès. GET demande une représentation actuelle. PUT vise la création ou le remplacement de l’état représenté à une cible choisie. DELETE demande la suppression de l’association entre l’URI et sa fonctionnalité actuelle ; il ne garantit pas l’effacement physique de toute copie.

Une méthode normalisée conserve sa sémantique d’une ressource à l’autre. C’est ce qui permet à des composants génériques de raisonner. Mais chaque ressource reste libre de mettre en œuvre ou d’admettre cette méthode. L’uniformité porte sur le sens de la demande, pas sur l’obligation d’y répondre.

La distinction se lit dans les erreurs. Une méthode inconnue ou non mise en œuvre appelle 501. Une méthode connue mais non prise en charge par la ressource cible appelle 405, avec un champ Allow indiquant les méthodes actuellement disponibles. Cette liste peut changer.

Allow décrit une capacité de la ressource. Ce n’est pas une liste des personnes autorisées. Une collection peut accepter POST tout en le refusant à un visiteur anonyme. Un document peut supporter PUT sans donner à chaque compte le droit de le modifier. Reconnaissance du mot, capacité de la cible et permission du principal sont trois reçus différents.

On retrouve ici la logique de la Minimum Initial Specification de Heng Lu : le commun doit être précis là où l’interopérabilité l’exige, puis laisser les décisions futures aux participants qui exploitent effectivement la ressource. Le registre des méthodes coordonne un vocabulaire ; il n’administre pas les droits de chaque application.

« Safe » distribue la responsabilité au lieu d’abolir les effets

Une méthode sûre est essentiellement en lecture seule dans sa sémantique définie. Le client ne demande pas de changement d’état. La RFC 9110 précise pourtant qu’un serveur peut écrire un journal, qu’un clic publicitaire peut facturer un compte et qu’une implémentation peut provoquer d’autres effets. Ce qui compte est que le client ne les a pas demandés et ne peut en être tenu responsable.

La nuance rend possibles les robots d’indexation, la prélecture et la vérification de liens. Elle impose en retour une discipline au propriétaire de la ressource. Une URL telle que page?do=delete ne doit jamais déclencher une suppression lorsqu’elle est visitée avec GET. Cacher une commande dangereuse dans un paramètre ne modifie pas la sémantique de la méthode.

Il faut donc consigner deux plans. Le premier décrit le changement demandé par le client. Le second décrit les effets choisis par le serveur : journalisation, facturation, consommation de quota, déclenchement externe. Confondre les deux permet à l’implémentation de faire porter au client la responsabilité de sa propre architecture.

Sûr ne signifie pas public non plus. La lecture d’un dossier confidentiel peut être sûre au sens de HTTP et interdite à ce principal. La propriété guide l’automatisation ; l’autorisation protège l’accès.

L’idempotence préserve une intention, pas une photographie

Une méthode est idempotente si plusieurs requêtes identiques ont sur le serveur le même effet voulu qu’une seule. PUT, DELETE et les méthodes sûres possèdent cette propriété dans la RFC 9110. Le serveur peut néanmoins enregistrer chaque tentative, conserver plusieurs révisions ou produire des réponses différentes.

Après un premier DELETE réussi, un second peut répondre que la ressource est absente. L’état recherché demeure le même. Après un PUT, la date, le validateur ou la représentation de résultat peuvent évoluer sans que l’intention de remplacement change.

Le contrat applicatif reste décisif. Un endpoint présenté comme PUT mais qui incrémente un solde au lieu de remplacer un état trahit la sémantique visible. Une suppression locale qui réexpédie à chaque tentative un ordre irréversible vers un tiers peut converger dans la ressource tout en multipliant les dommages ailleurs.

L’étiquette de méthode doit donc être complétée par une clé d’opération, un état de commit, une déduplication et, pour chaque système aval, une possibilité de compensation. L’idempotence protocolaire est une base de raisonnement, pas une transaction distribuée.

La reprise traite d’abord une première tentative inconnue

Quand une connexion tombe avant la réponse, le client ignore souvent si le serveur a appliqué la demande. La requête peut n’être jamais arrivée, avoir été validée avant la rupture, ou avoir produit une réponse perdue. Répéter une méthode idempotente est utile parce que la seconde tentative devrait conduire au même effet voulu.

Cette permission de raisonner n’est pas une boucle automatique infinie. La RFC déconseille de reprendre automatiquement une méthode non idempotente sans connaissance spécifique de la ressource ou preuve que la première tentative n’a pas été appliquée. Un proxy ne doit pas effectuer cette reprise. Le client ne devrait pas recommencer automatiquement après l’échec d’une première reprise automatique.

Le bon dossier contient le point de rupture, la cible, le contenu, les préconditions, la clé d’idempotence applicative et le statut consultable de l’opération. POST peut être repris de manière sûre si l’application possède ces garanties. PUT peut devenir dangereux si ses effets aval échappent à toute déduplication.

La Running-Code Primacy ramène ici la preuve au comportement observable : les doublons convergent-ils réellement, le commit peut-il être interrogé, les conséquences restent-elles bornées ? Le nom institutionnel d’une propriété ne remplace pas ce test.

Une précondition protège une version, jamais une identité

If-Match permet d’exiger que la représentation actuelle porte encore un ETag connu avant d’appliquer une modification. Si la condition échoue, la méthode n’est pas exécutée et la réponse normale est 412. L’éditeur évite ainsi d’écraser le travail intervenu depuis sa lecture.

Un ETag n’est pas un justificatif d’identité. Le connaître ne donne aucun droit d’écriture. Inversement, un compte autorisé ne rend pas actuel un validateur périmé. L’autorisation et la précondition répondent à deux risques : agir sans droit, et agir sur un état qui n’est plus celui supposé.

Après une réponse perdue, la précondition peut aider à reconnaître qu’une modification a déjà été appliquée. Mais la RFC avertit que des auteurs non coordonnés produisant des changements similaires exigent parfois une réponse stricte. Le modèle d’une ressource est donc aussi important que le verbe.

QUERY rend visible une propriété auparavant privée

La RFC 10008, publiée en juin 2026 par Julian Reschke, James Snell et Mike Bishop, définit QUERY. Elle ne doit pas être attribuée à Fielding. QUERY transporte un contenu de requête comme POST, mais annonce une consultation sûre et idempotente. L’IANA l’inscrit désormais avec les deux propriétés à « yes ».

Le besoin naît d’une asymétrie. Une requête complexe tient mal dans une URI et peut exposer ses paramètres dans des journaux. Beaucoup d’applications utilisent alors POST pour lire. Un composant générique ne peut pas deviner que ce POST particulier est sans modification et répétable. QUERY rend la propriété commune sans dicter le format de la requête à la ressource.

L’enregistrement n’impose aucune adoption. Un serveur peut ne pas mettre QUERY en œuvre, une passerelle peut ne pas le transmettre, un principal peut ne pas être autorisé. Le registre fournit une grammaire commune lorsque les acteurs choisissent de l’utiliser. Ce n’est ni un déploiement ni une ACL.

L’apport de Fielding tient à la frontière de l’interface

Au 31 août 2026, le Datatracker IETF décrit Roy T. Fielding comme Senior Principal Scientist chez Adobe, cofondateur de The Apache Software Foundation, auteur de REST et contributeur aux normes HTTP, URI et URI Templates. Il recense 18 RFC et une fonction de relecteur à l’HTTP Directorate. UC Irvine documente ses diplômes et ses contributions au Web et à Apache.

Sa thèse présente l’interface uniforme de REST comme un compromis : davantage de visibilité, de réutilisation et d’évolution indépendante, au prix d’une efficacité parfois moindre qu’une interface faite sur mesure. Le vocabulaire des méthodes illustre ce compromis. Il montre assez pour coordonner des composants autonomes, sans révéler ni centraliser toute la logique applicative.

L’attribution a ses limites. La RFC 9110 compte trois éditeurs : Fielding, Mark Nottingham et Julian Reschke. HTTP est une œuvre collective et révisée. Les implémentations décident pour elles-mêmes. La signature d’un éditeur rend la contribution traçable ; elle ne crée ni propriété du protocole ni autorité sur les ressources.

Le reçu d’opération que le verbe ne peut pas fournir

Pour une action sensible, noter la méthode et l’URI cible, puis le principal authentifié, la portée du justificatif, les méthodes supportées, la décision d’autorisation et sa version, l’ETag ou toute précondition, le hachage du contenu et l’effet voulu.

En cas de rupture, ajouter le dernier point de transmission confirmé, la possibilité que la première tentative ait abouti, la clé d’opération, l’auteur de la reprise, son déclencheur, son numéro et son délai. Terminer par la réponse, l’état relu, les effets aval, les compensations et ce qui ne peut plus être annulé.

Le jeton de méthode retrouve alors sa juste taille. Il dit ce que le client veut demander. La ressource dit si elle comprend. La politique dit si ce principal peut agir. La précondition dit si l’état attendu existe encore. Les preuves de reprise disent s’il faut recommencer. L’observation finale dit ce qui s’est produit.

Une méthode nomme l’intention. Elle ne confère pas la permission.

Sources