Méthodes HTTP - GET VS POST | W3Docs

HTTP (Hypertext Transfer Protocol) a été créé pour permettre la communication entre les clients et un serveur. Il fonctionne selon un modèle requête-réponse : le client envoie une requête qui spécifie une méthode HTTP (également appelée verbe HTTP), et la méthode indique au serveur quel type d'action effectuer sur la ressource cible.

Un élément HTML <form> ne prend en charge nativement que deux de ces méthodes — GET et POST — via son attribut method. C'est pourquoi ces deux méthodes sont les premières que rencontrent la plupart des développeurs HTML. Mais HTTP lui-même définit plusieurs autres méthodes (PUT, PATCH, DELETE, HEAD, OPTIONS, CONNECT), accessibles via JavaScript (fetch) ou votre backend lors de la création d'API REST.

Deux propriétés clés : Sûre et Idempotente

Avant d'examiner chaque méthode individuellement, deux termes décrivent le comportement de chacune. Ils sont utilisés tout au long de cette page et dans les spécifications HTTP.

Sûre — la méthode est en lecture seule. Elle ne doit pas modifier l'état du serveur. Récupérer une page ne devrait jamais créer, mettre à jour ou supprimer quoi que ce soit. GET, HEAD et OPTIONS sont sûres.
Idempotente — effectuer la même requête une ou plusieurs fois produit le même effet sur le serveur. Envoyer une requête DELETE pour une ressource une fois ou cinq fois laisse la ressource supprimée dans les deux cas. Les méthodes sûres sont toujours idempotentes, mais une méthode peut être idempotente sans être sûre (par exemple PUT et DELETE).

Voici comment les méthodes courantes se comparent :

Méthode	Sûre	Idempotente	Corps de requête	Utilisation typique
GET	Oui	Oui	Non	Récupérer une ressource
HEAD	Oui	Oui	Non	Récupérer uniquement les en-têtes
OPTIONS	Oui	Oui	Non	Découvrir les méthodes autorisées / Pré-vérification CORS
POST	Non	Non	Oui	Créer une ressource ou soumettre des données
PUT	Non	Oui	Oui	Remplacer / mettre à jour une ressource à une URL connue
PATCH	Non	Non garantie	Oui	Appliquer une modification partielle
DELETE	Non	Oui	Généralement non	Supprimer une ressource

Info

PATCH n'est pas garantie d'être idempotente. Selon la façon dont le patch est écrit, il peut l'être (par exemple, "définir status à active") ou ne pas l'être (par exemple, "incrémenter le compteur de 1"). La spécification HTTP laisse cela à l'implémentation.

Méthode GET

La méthode GET demande des données à une source spécifiée. Elle est sûre et idempotente : elle ne fait que lire des données et ne modifie jamais rien sur le serveur. Les requêtes GET peuvent être mises en cache et restent dans l'historique du navigateur. Elles peuvent également être ajoutées aux favoris.

Elle ne doit jamais être utilisée pour des données sensibles, car la chaîne de requête fait partie de l'URL (qui est journalisée, mise en cache et enregistrée dans les favoris). Les requêtes GET ont des limites de longueur pratiques et ne doivent être utilisées que pour récupérer des données.

Danger

Les chaînes de requête (paires nom/valeur) sont envoyées dans l'URL de la requête GET.

Exemple d'un champ de texte utilisant la méthode get

<!DOCTYPE html>
<html>
  <head>
    <title>Title of the document</title>
  </head>
  <body>
    <form action="/form/submit" method="get">
      First name:
      <input type="text" name="username" placeholder="Your name" />
      <br />
      <br />
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

Essayez vous-même »

Méthode POST

La méthode POST soumet des données à traiter à une source spécifiée. Elle n'est ni sûre ni idempotente : elle peut modifier l'état du serveur, et soumettre le même formulaire deux fois crée généralement deux enregistrements — c'est pourquoi les navigateurs vous avertissent avant de renvoyer des données POST. Contrairement à la méthode GET, les requêtes POST ne sont jamais mises en cache, ne restent pas dans l'historique du navigateur et ne peuvent pas être ajoutées aux favoris. De plus, les requêtes POST ne sont pas soumises aux restrictions de longueur d'URL, bien que les serveurs imposent généralement leurs propres limites de taille du corps.

Danger

Les chaînes de requête (paires nom/valeur) sont envoyées dans le corps du message HTTP de la requête POST.

Exemple d'un formulaire avec la méthode « post »

<!DOCTYPE html>
<html>
  <head>
    <title>Title of the document</title>
  </head>
  <body>
    <form action="/form/submit" method="post">
      First name:
      <input type="text" name="username" placeholder="Your name" />
      <br /><br />
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

Essayez vous-même »

Comparaison des méthodes GET et POST

Fonctionnalité	GET	POST
Bouton Précédent/Actualiser	Sans danger	Actualiser la page resoumettra les données du formulaire. Le navigateur doit avertir que les données seront renvoyées dans ce cas.
Peut être ajouté aux favoris	Oui	Non
Peut être mis en cache	Oui	Non
Type d'encodage	application/x-www-form-urlencoded	application/x-www-form-urlencoded ou multipart/form-data
Historique	Reste dans l'historique du navigateur.	Ne reste pas dans l'historique du navigateur.
Restrictions de longueur des données	Lors de l'envoi de données, la méthode GET ajoute les données à l'URL. La longueur de l'URL est limitée (longueur maximale : 2048 caractères).	N'a pas de restrictions de longueur d'URL, bien que les serveurs imposent généralement des limites de taille du corps.
Restriction du type de données	Principalement des caractères ASCII, bien que UTF-8 soit pris en charge via le codage en pourcentage.	N'a pas de restrictions. Les données binaires sont également autorisées.
Sécurité	Moins sécurisée que POST, car les données envoyées font partie de l'URL.	POST est plus sécurisée que GET, car les données ne sont pas visibles dans l'URL ni dans l'historique du navigateur. Cependant, les deux transmettent les données en texte clair sur HTTP et nécessitent HTTPS pour une sécurité réelle.
Visibilité	Les données sont visibles par tous dans l'URL.	N'affiche pas les données dans l'URL.

Remarque L'élément HTML <form> ne prend en charge nativement que GET et POST via son attribut method. Pour utiliser PUT, PATCH ou DELETE, vous envoyez généralement la requête avec JavaScript (fetch) ou laissez votre framework backend remplacer la méthode.

HEAD, OPTIONS et CONNECT

En plus de GET et POST, HTTP définit plusieurs autres méthodes. Trois d'entre elles sont décrites ici ; les méthodes orientées ressources PUT, PATCH et DELETE suivent dans leurs propres sections.

Méthode	Sûre	Idempotente	Description
HEAD	Oui	Oui	Identique à GET, mais le serveur ne renvoie que les en-têtes HTTP, pas le corps de la réponse.
OPTIONS	Oui	Oui	Demande au serveur quelles méthodes et options sont disponibles pour une ressource.
CONNECT	Non	Non	Établit un tunnel vers le serveur, utilisé par les proxies pour HTTPS.

HEAD

HEAD fonctionne exactement comme GET, mais le serveur omet le corps et ne renvoie que les en-têtes. Étant donné qu'elle est sûre et idempotente, elle est idéale lorsque vous avez besoin de métadonnées sans télécharger l'intégralité de la ressource — par exemple, vérifier le Content-Length d'un fichier volumineux avant de le télécharger, ou tester si une URL est toujours accessible (son code de statut) sans transférer son contenu.

OPTIONS

OPTIONS demande au serveur ce qu'il autorise pour une ressource. La réponse inclut généralement un en-tête Allow listant les méthodes prises en charge (par exemple Allow: GET, POST, OPTIONS). Son utilisation la plus importante en pratique est la requête de pré-vérification CORS : avant qu'un navigateur envoie une requête PUT, DELETE ou une requête avec des en-têtes personnalisés vers une autre origine, il envoie automatiquement une requête OPTIONS pour confirmer que le serveur autorise l'appel réel. Vous écrirez rarement des requêtes OPTIONS à la main — le navigateur le fait pour vous.

CONNECT

CONNECT demande à un serveur proxy d'établir un tunnel TCP/IP transparent vers la destination, le plus souvent pour que le trafic HTTPS chiffré puisse traverser le proxy sans être lu. Elle est utilisée par l'infrastructure plutôt que par le code applicatif, donc vous ne l'appellerez presque jamais directement.

Méthode PUT

La méthode PUT est principalement utilisée pour remplacer ou mettre à jour une ressource. Le client envoie l'URL de la ressource cible avec un corps de requête contenant la représentation complète et mise à jour de cette ressource. PUT peut également créer une ressource lorsque c'est le client (et non le serveur) qui décide de l'URL de la ressource.

PUT n'est pas sûre, car elle modifie l'état sur le serveur, mais elle est idempotente : si vous envoyez la même requête PUT deux fois, la ressource se retrouve dans exactement le même état qu'après une seule requête — le corps remplace entièrement ce qui était là.

L'exemple ci-dessous demande au serveur de stocker le corps JSON donné comme ressource à /users/42 :

Méthodes HTTP - Exemple de requête PUT

PUT /users/42 HTTP/1.1
Host: www.w3docs.com
Accept-Language: en-us
Connection: keep-alive
Content-Type: application/json
Content-Length: 54

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

Après avoir stocké le corps, le serveur pourrait répondre comme suit :

Méthodes HTTP - Exemple de réponse PUT

HTTP/1.1 200 OK
Date: Mon, 15 Jun 2026 14:53:57 GMT
Content-Type: application/json
Content-Length: 54
Connection: keep-alive

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

Méthode PATCH

La méthode PATCH est utilisée pour la modification partielle d'une ressource. Contrairement à PUT, elle n'a pas besoin de l'intégralité de la ressource — le corps ne contient que les modifications à appliquer.

PATCH n'est pas sûre, et il n'est pas garanti qu'elle soit idempotente : selon le format du patch, elle peut ou non produire le même résultat lorsqu'elle est répétée. Un patch tel que "définir status à active" est idempotent, mais un patch tel que "ajouter 1 à views" ne l'est pas. Les collisions entre deux requêtes PATCH peuvent également être dangereuses, car certains formats de patch s'attendent à appliquer des modifications à partir d'un état de base partagé ; sinon, la ressource peut être corrompue.

L'exemple ci-dessous ne modifie que le champ email de l'utilisateur, laissant tous les autres champs intacts :

Méthodes HTTP - Exemple de requête PATCH

PATCH /users/42 HTTP/1.1
Host: www.w3docs.com
Content-Type: application/json
Content-Length: 31

{ "email": "[email protected]" }

HTTP/1.1 200 OK
Date: Mon, 15 Jun 2026 14:53:57 GMT
Content-Type: application/json
Connection: keep-alive

Méthode DELETE

Comme son nom l'indique, cette méthode supprime la ressource identifiée par une URL. DELETE n'est pas sûre mais est idempotente : une fois qu'une ressource est supprimée, appeler DELETE à nouveau la laisse supprimée — l'état final est le même. (Les appels répétés peuvent renvoyer un code de statut différent, tel que 404 Not Found au deuxième essai, mais l'état du serveur ne change pas davantage.)

L'exemple ci-dessous demande au serveur de supprimer l'utilisateur à /users/42 :

Exemple de requête DELETE

DELETE /users/42 HTTP/1.1
Host: www.w3docs.com
Accept-Language: en-us
Connection: keep-alive

Après avoir supprimé la ressource, le serveur répond généralement avec 204 No Content — un statut de succès sans corps de réponse :

Exemple de réponse DELETE

HTTP/1.1 204 No Content
Date: Mon, 15 Jun 2026 14:53:57 GMT
Connection: keep-alive

Une réponse 200 OK (optionnellement avec un corps décrivant la ressource supprimée) est également une réponse DELETE valide. Consultez les messages de statut HTTP pour la liste complète des codes de statut.