Consultez n’importe quelle méthode de requête HTTP enregistrée : ce qu’elle fait, la spécification qui la définit et son caractère sûr et idempotent. Le tableau couvre les neuf méthodes de base et les extensions WebDAV, DeltaV et CalDAV.
Fonctionne localement dans votre navigateurLes méthodes de requête HTTP indiquent ce qu’une requête doit faire. Neuf méthodes de base viennent de HTTP lui-même — GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE et PATCH ; les autres sont des extensions enregistrées pour WebDAV, le versionnement et l’agenda, plus deux méthodes retirées par les révisions suivantes de HTTP. Le tableau reprend toutes les méthodes du registre IANA des méthodes HTTP, avec la spécification qui les définit et leur caractère sûr et idempotent.
| Méthode | Défini dans | Sûr / idempotent | Rôle |
|---|---|---|---|
| Méthodes de base | |||
| GET | RFC 9110 §9.3.1 | oui / oui | Récupérer une représentation de la ressource cible. |
| HEAD | RFC 9110 §9.3.2 | oui / oui | Récupérer uniquement les en-têtes de la réponse, sans le corps. |
| POST | RFC 9110 §9.3.3 | non / non | Envoyer des données à traiter à la ressource cible ; crée souvent une ressource ou déclenche une action. |
| PUT | RFC 9110 §9.3.4 | non / oui | Créer la ressource cible ou la remplacer par le contenu de la requête. |
| DELETE | RFC 9110 §9.3.5 | non / oui | Supprimer la ressource cible. |
| CONNECT | RFC 9110 §9.3.6 | non / non | Ouvrir un tunnel vers l’autorité cible, généralement via un proxy. |
| OPTIONS | RFC 9110 §9.3.7 | oui / oui | Demander les méthodes et options prises en charge par la ressource cible. |
| TRACE | RFC 9110 §9.3.8 | oui / oui | Demander au serveur de renvoyer la requête reçue pour diagnostic. |
| PATCH | RFC 5789 §2 | non / non | Appliquer à la ressource cible les changements décrits dans le contenu de la requête. |
| Extensions WebDAV | |||
| PROPFIND | RFC 4918 §9.1 | oui / oui | Lire les propriétés d’une ressource ; l’en-tête Depth fixe la profondeur. |
| PROPPATCH | RFC 4918 §9.2 | non / oui | Définir ou supprimer plusieurs propriétés d’une ressource en une requête. |
| MKCOL | RFC 4918 §9.3 | non / oui | Créer une collection, la ressource WebDAV qui ressemble à un dossier. |
| COPY | RFC 4918 §9.8 | non / oui | Copier une ressource vers l’URI indiquée dans l’en-tête Destination. |
| MOVE | RFC 4918 §9.9 | non / oui | Déplacer une ressource vers l’URI indiquée dans l’en-tête Destination. |
| LOCK | RFC 4918 §9.10 | non / non | Verrouiller une ressource en écriture et renvoyer un jeton de verrou. |
| UNLOCK | RFC 4918 §9.11 | non / oui | Libérer un verrou avec le jeton de l’en-tête Lock-Token. |
| ACL | RFC 3744 §8.1 | non / oui | Lire ou modifier la liste de contrôle d’accès d’une ressource. |
| SEARCH | RFC 5323 §2 | oui / oui | Exécuter une requête DASL sur une collection et renvoyer les ressources trouvées. |
| MKCALENDAR | RFC 4791 §5.3.1 | non / oui | Créer une collection calendrier avec ses propriétés. |
| BIND | RFC 5842 §4 | non / oui | Ajouter une ressource existante à une collection comme nouvelle liaison. |
| UNBIND | RFC 5842 §5 | non / oui | Retirer une liaison d’une collection. |
| REBIND | RFC 5842 §6 | non / oui | Déplacer une liaison d’une collection vers une autre. |
| ORDERPATCH | RFC 3648 §7 | non / oui | Modifier la position des membres d’une collection ordonnée. |
| MKREDIRECTREF | RFC 4437 §6 | non / oui | Créer une ressource de référence de redirection vers un autre URI. |
| UPDATEREDIRECTREF | RFC 4437 §7 | non / oui | Changer l’URI cible d’une ressource de référence de redirection. |
| Extensions de versionnement (DeltaV) | |||
| VERSION-CONTROL | RFC 3253 §3.5 | non / oui | Placer une ressource sous contrôle de version. |
| REPORT | RFC 3253 §3.6 | oui / oui | Demander un rapport de version, de propriétés ou DAV sur une ressource. |
| CHECKOUT | RFC 3253 §8.8 | non / oui | Rendre une ressource versionnée inscriptible ou créer une ressource de travail. |
| CHECKIN | RFC 3253 §9.4 | non / oui | Enregistrer les changements comme nouvelle version et repasser la ressource en lecture seule. |
| UNCHECKOUT | RFC 3253 §4.5 | non / oui | Annuler un checkout et abandonner les changements non validés. |
| MKWORKSPACE | RFC 3253 §6.3 | non / oui | Créer un espace de travail pour le travail versionné. |
| UPDATE | RFC 3253 §7.1 | non / oui | Appliquer les changements d’une version à une autre ressource. |
| LABEL | RFC 3253 §8.2 | non / oui | Ajouter ou retirer une étiquette sur les versions. |
| MERGE | RFC 3253 §11.2 | non / oui | Fusionner les différences entre deux historiques de versions. |
| BASELINE-CONTROL | RFC 3253 §12.6 | non / oui | Transformer une collection en collection contrôlée par ligne de base. |
| MKACTIVITY | RFC 3253 §13.5 | non / oui | Créer une activité qui regroupe des changements sur plusieurs ressources. |
| Autres méthodes enregistrées | |||
| QUERY | RFC 10008 §2 | oui / oui | Envoyer une requête sûre et idempotente dont les paramètres sont dans le contenu. |
| PRI | RFC 9113 §3.4 | oui / oui | Envoyé uniquement dans le préambule de connexion HTTP/2, avant toute trame. |
| Retirés de HTTP | |||
| LINK | RFC 2068 §19.6.1.2 | non / oui | Défini dans la RFC 2068 pour créer des liens entre ressources ; retiré par les révisions suivantes de HTTP. |
| UNLINK | RFC 2068 §19.6.1.3 | non / oui | Défini dans la RFC 2068 pour supprimer des liens entre ressources ; retiré par les révisions suivantes de HTTP. |
Cette page reprend toutes les méthodes du registre IANA des méthodes HTTP, tenu par l’IETF. Chaque ligne donne le nom de la méthode, la spécification qui la définit, son caractère sûr et idempotent, et une ligne sur ce qu’elle fait.
Les lignes font partie de la page : rien n’est généré à l’exécution, aucune saisie n’est demandée et aucune requête n’est envoyée pendant la lecture. Le champ de recherche ne filtre le tableau que dans votre navigateur.
Une méthode est sûre lorsque la spécification la définit comme lecture seule : GET, HEAD, OPTIONS, TRACE, PROPFIND, REPORT, SEARCH, QUERY et PRI sont marquées sûres dans le registre. Sûr décrit l’intention, pas les effets qu’un serveur ajoute : une requête GET peut être journalisée, comptée ou facturée.
Une méthode est idempotente lorsque rejouer la même requête produit le même effet que de l’envoyer une fois. PUT, DELETE et presque toutes les méthodes WebDAV et DeltaV sont idempotentes ; POST, PATCH, CONNECT et LOCK ne le sont pas, donc un client ou un proxy ne doit pas les rejouer automatiquement après un délai dépassé.
L’IANA met le registre à jour à chaque publication de méthode, et ce tableau le suit : le nom, les indicateurs sûr et idempotent et la première spécification citée. Lorsque le registre mentionne d’autres spécifications — MKCOL est étendue par la RFC 5689, PROPFIND et REPORT par la RFC 8144 — c’est la RFC qui définit la méthode qui est affichée.
Des méthodes hors registre existent. Le SSDP d’UPnP envoie M-SEARCH en UDP, la RFC 2774 définit des méthodes d’extension à préfixe M- comme M-GET, et beaucoup d’API inventent leurs propres verbes ; un serveur qui ne connaît pas la méthode répond 405 Method Not Allowed et un proxy peut la refuser d’emblée.
LINK et UNLINK viennent de la RFC 2068, la première spécification de HTTP/1.1, et ont été retirées ensuite : le registre les conserve avec leur référence de brouillon, mais aucune spécification HTTP actuelle ne les utilise.
PRI est envoyé une fois par connexion, dans le préambule de connexion HTTP/2, avant toute trame ; le registre liste aussi la forme astérisque, utilisée comme OPTIONS * pour viser le serveur entier plutôt qu’une ressource. Les deux sont faciles à confondre dans un journal de requêtes.