Quelles sont les principales différences entre les méthodes de requête HTTP GET et POST ?

Objectif

• GET demande une représentation d’une ressource. Selon la spécification, elle est en lecture seule : le client ne s’attend à aucun changement d’état côté serveur. La RFC 9110 précise que l’envoi d’un corps dans une requête GET a une sémantique indéfinie ; GET ne doit donc pas transporter de corps.
• POST demande à la ressource cible de traiter les données contenues dans le corps de la requête selon la sémantique propre à cette ressource (créer un enregistrement, soumettre un formulaire, téléverser un fichier, etc.).

Où vont les données

• GET transporte les paramètres dans la chaîne de requête de l’URL (après ?, formatée comme key=value&...). Ceux-ci sont visibles dans la barre d’adresse et consignés dans l’historique du navigateur et les journaux du serveur, et sont limités par une longueur d’URL pratique.
• POST transporte les données dans le corps de la requête ; le type est indiqué par l’en-tête Content-Type. Les formulaires HTML utilisent généralement application/x-www-form-urlencoded (la valeur par défaut) ou multipart/form-data (pour les fichiers). Il n’existe pas de limite fixe au niveau du protocole, mais les serveurs et les proxys configurent leurs propres maximums (par exemple Nginx client_max_body_size).

Propriétés selon la RFC 9110

• Sûre : GET est sûre (lecture seule) ; POST ne l’est pas.
• Idempotente : une requête est idempotente si l’exécuter N fois a le même effet sur l’état du serveur que l’exécuter une fois. GET est idempotente ; POST ne l’est pas — la répéter peut créer des doublons, comme deux commandes identiques. Idempotent n’est pas synonyme de sûr (PUT et DELETE sont idempotents mais pas sûrs), et cela ne dit rien sur l’identité du corps de la réponse.
• Mise en cache : les réponses GET sont mises en cache par défaut ; les réponses POST ne le sont que lorsqu’elles incluent des informations explicites de fraîcheur et un en-tête Content-Location correspondant, ce qui est rare en pratique.

Implications pratiques

• Utilisez GET pour la récupération et la navigation ; les résultats peuvent être répétés, ajoutés aux favoris et récupérés à l’avance en toute sécurité, et actualiser une page GET est sans danger.
• Utilisez POST pour les actions modifiant l’état et pour l’envoi de charges utiles sensibles ou volumineuses. Rafraîchir ou revenir à une page POST déclenche l’avertissement du navigateur « confirmer la re-soumission du formulaire ».
• N’envoyez jamais de mots de passe via GET — ils se retrouveraient dans l’URL, les journaux et l’historique. Il s’agit d’hygiène, pas de chiffrement : HTTPS chiffre à la fois l’URL et le corps en transit, mais l’URL est quand même consignée.

Questions fréquentes

• Les méthodes sûres sont GET, HEAD, OPTIONS ; les méthodes idempotentes sont GET, HEAD, PUT, DELETE ; POST n’est ni l’une ni l’autre.
• Les deux méthodes sont prises en charge par les formulaires HTML (l’attribut method).
• « Sûr » au sens de la RFC signifie absence de changement d’état, pas protection des données.
• L’idempotence de POST au niveau de l’application est souvent assurée à l’aide de clés d’idempotence.