Aussi disponible en : English · Español · Português · العربية
Méthodes HTTP : sûres, idempotentes, cachables
Toutes les méthodes enregistrées par l'IANA, et ce que chacune signifie pour un robot, un mandataire et un cache.
Qu'est-ce qu'une méthode HTTP ?
Une méthode HTTP — le verbe qui ouvre une requête, GET ou POST ou DELETE — dit ce que le client veut faire de la ressource qu'il désigne. Il y en a bien plus qu'on n'en croise : le registre de l'IANA en compte 41, dont neuf seulement viennent de la spécification centrale de HTTP. Le reste arrive de WebDAV, des extensions de versionnement, de CalDAV, de HTTP/2 et de trois spécifications isolées.
La RFC 9110 attribue trois propriétés à chaque méthode. Elle est sûre si sa sémantique est essentiellement en lecture seule, si bien qu'un robot peut l'émettre sans crainte. Elle est idempotente si envoyer deux fois la même requête produit l'effet d'un seul envoi, si bien qu'un mandataire peut la rejouer après une coupure. Et elle est cachable si un cache peut stocker la réponse et la réutiliser plus tard.
Ces trois réponses sont ce qu'une page sur les méthodes HTTP devrait donner, et elles ne se trouvent pas au même endroit : c'est la raison d'être de cette page plutôt que d'une copie du registre.
Comment l'utiliser
- Tapez le nom d'une méthode sans vous soucier de la casse. Vous obtenez les trois propriétés, ce que chacune implique concrètement pour un client et pour un cache, et un lien vers la section de la RFC qui l'affirme.
- Ou fouillez le registre entier dans le tableau ci-dessous, qui contient les 41 noms. Chercher un numéro de RFC — 9110, 4918 — ramène tout ce que ce document définit.
- Ramenez-le à celles que vous rencontrerez vraiment grâce à une case à cocher qui réduit le tableau aux neuf noms que la RFC 9110 enregistre elle-même, c'est-à-dire toutes les méthodes que la plupart des API émettent jamais.
La propriété que le registre ne consigne pas
La section 16.1.1 de la RFC 9110 énumère les champs qu'un enregistrement de méthode doit porter : le nom, si elle est sûre, si elle est idempotente, et un renvoi vers la spécification. Quatre champs, et la cachabilité n'en fait pas partie. Pourtant la section 16.1.2 du même document dit que la définition d'une nouvelle méthode doit indiquer si elle est sûre, idempotente et cachable. Trois propriétés nommées à une section d'intervalle, deux consignées.
La troisième doit donc être lue dans les documents qui définissent chaque méthode, et il y en a treize. L'exercice donne une réponse nette pour la plupart des lignes et une réponse embarrassante pour le reste : 3 méthodes sont cachables sans réserve, 3 autres uniquement sous des conditions énoncées, 26 ne le sont explicitement pas, et 9 spécifications ne parlent jamais de cache.
Ce silence n'est pas une inconnue, et voici la phrase qui rend le tableau complet plutôt que partiel. Section 9.2.3 : pour qu'un cache stocke et utilise une réponse, la méthode doit autoriser explicitement la mise en cache et détailler à quelles conditions, et une méthode dont la définition ne le fait pas ne peut pas être mise en cache. Le silence vaut refus, par défaut, et c'est le standard lui-même qui l'écrit. Le tableau affiche malgré tout ces neuf lignes comme « non précisé » et non comme « non », parce que ce qu'une spécification interdit et ce qu'elle n'a jamais envisagé sont deux faits distincts, et un seul des deux se cite en revue de code.
Les formulations diffèrent aussi, et cela mérite d'être vu. Huit méthodes disent que les réponses NE DOIVENT PAS être mises en cache, ce qui lie le cache. Dix — la famille du versionnement, plus MKCALENDAR — exigent au contraire que le serveur envoie Cache-Control: no-cache, ce qui lie le serveur. SEARCH dit seulement NE DEVRAIENT PAS. PROPFIND dit que les résultats peuvent être mis en cache, avec précaution. Le tableau note quelle formulation a produit chaque réponse.
Les lignes que tout le monde se rate
PATCH n'est pas idempotente. Elle figure à côté de PUT dans tous les tutoriels REST et se comporte autrement : appliquer deux fois le même correctif ne revient pas forcément à l'appliquer une fois, donc le registre la note ni sûre ni idempotente, et la RFC 9110 dit qu'un mandataire ne doit pas rejouer automatiquement une requête pareille. DELETE, à l'inverse, est bel et bien idempotente malgré son air de verbe le plus destructeur de la liste : supprimer deux fois une chose la laisse supprimée.
Sûre ne veut pas dire cachable. Neuf méthodes sont sûres et trois seulement — GET, HEAD et QUERY — sont cachables sans réserve. OPTIONS et TRACE sont en lecture seule et leurs réponses ne sont explicitement jamais cachables. REPORT est sûre, idempotente, et sa spécification ne dit rien du tout sur le cache.
La réciproque échoue également : POST et PATCH ne sont ni sûres ni idempotentes, et toutes deux sont cachables sous conditions. Une réponse à POST peut être stockée si elle porte une information de fraîcheur explicite et un Content-Location identique à la cible de la requête — et elle ne peut alors servir qu'à répondre à un GET ou un HEAD ultérieur, jamais à un autre POST. La RFC 9110 note au passage que l'écrasante majorité des caches n'implémentent de toute façon que GET et HEAD, ce qui est une spécification reconnaissant que la réalité lui a échappé.
Deux curiosités encore. QUERY est une méthode de voie normalisée depuis juin 2026 : sûre, idempotente, cachable, et porteuse d'un corps de requête — exactement ce que l'on réclame chaque fois qu'on essaie de faire tenir une longue recherche dans un GET. Sa clé de cache doit incorporer ce corps, ce qui explique précisément l'attente. Et le registre contient une entrée nommée simplement astérisque, qui n'est pas une méthode : elle est réservée pour que personne ne puisse jamais en enregistrer une, car ce nom entrerait en conflit avec le joker de champs comme Access-Control-Request-Method.
Ce que cette page ne peut pas vous dire
Ce sont des propriétés de la méthode, pas des promesses sur un serveur. Un serveur peut implémenter GET de façon à supprimer quelque chose ; la spécification est claire, cela rend le serveur fautif et non GET dangereuse. Ce que les propriétés achètent, c'est le droit de supposer : un robot préchargeant les méthodes sûres, un mandataire rejouant les idempotentes, un cache stockant les cachables, sans demander l'avis de personne.
Le tableau est en outre l'instantané d'un registre qui grandit. QUERY y est entrée en 2026 et rien ici ne prédit la suite. Là où une ligne indique qu'une spécification se tait, cela décrit le document tel qu'il est, non une promesse qu'il se taira toujours.
Enfin, qu'une méthode soit enregistrée ne dit rien de son implémentation quelque part. La plupart de ces 41 noms appartiennent à WebDAV et à ses extensions, et un serveur web ordinaire y répondra par un 405.
Pourquoi est-ce gratuit ?
Le registre entier tient en quelques kilo-octets livrés avec la page et consultés dans votre navigateur. Rien de ce que vous tapez n'est envoyé, rien n'est journalisé, et il n'y a aucun compte à créer.
Sans inscription, sans limite, et sans filigrane sur ce que vous copiez.