Quand dois-je utiliser la méthode GET ou POST? Quelle est la différence entre eux?


249

Quelle est la différence lors de l'utilisation GETou de la POSTméthode? Lequel est le plus sûr? Quels sont les (dés) avantages de chacun d'eux?

( question similaire )


2
Get n'a pas de corps, donc dans la pratique, vous êtes limité aux paires nom -> valeur en tant que structure de données en raison de l'absence de format de codage de chaîne de requête pour une structure plus complexe. Si vous devez gérer des structures de données plus complexes dans vos demandes (c'est-à-dire un tableau, un objet, etc.), vous devez utiliser POST et peut-être des formats plus avancés (json / xml). En bref: n'utilisez GET que si vous en avez vraiment besoin (c'est-à-dire que l'URL / la ressource doit être détectable).
themihai

Réponses:


263

Ce n'est pas une question de sécurité. Le protocole HTTP définit les requêtes de type GET comme étant idempotentes , tandis que les POST peuvent avoir des effets secondaires. En clair, cela signifie que GET est utilisé pour afficher quelque chose, sans le changer, tandis que POST est utilisé pour changer quelque chose. Par exemple, une page de recherche doit utiliser GET, tandis qu'un formulaire qui modifie votre mot de passe doit utiliser POST.

Notez également que PHP confond un peu les concepts. Une demande POST obtient une entrée à partir de la chaîne de requête et via le corps de la demande. Une requête GET obtient juste une entrée de la chaîne de requête. Ainsi, une demande POST est un sur-ensemble d'une demande GET; vous pouvez utiliser $_GETdans une requête POST, et il peut même être judicieux d'avoir des paramètres avec le même nom dans $_POSTet $_GETcela signifie des choses différentes.

Par exemple, supposons que vous ayez un formulaire pour modifier un article. L'ID d'article peut être dans la chaîne de requête (et donc disponible via $_GET['id']), mais disons que vous souhaitez modifier l'ID d'article. Le nouvel identifiant peut alors être présent dans le corps de la demande ( $_POST['id']). OK, ce n'est peut-être pas le meilleur exemple, mais j'espère que cela illustre la différence entre les deux.


13
Il y a définitivement un aspect de sécurité à la différence entre GET et POST. Un site malveillant peut par exemple coller une requête GET arbitraire dans une balise d'image, ce qui oblige les utilisateurs à effectuer une GET sur un autre serveur. Si ce GET est comme otherserver / deletemyaccount, de mauvaises choses se produisent.
Frank Schwieterman

2
Ce que je voulais dire, c'est que le contenu de $ _POST n'est pas comme par magie caché aux utilisateurs malveillants. Il y a évidemment des aspects de sécurité dans toute programmation.
troelskn

1
Ce message ne répond pas complètement à la question car il ne mentionne pas les implications pour la sécurité. La partie supérieure est bonne tant que l'erreur d'orthographe "pain English" est remplacée par "plain English". La partie inférieure est trop difficile à suivre. Dans l'ensemble, bien mieux que mon post-tho. :-)
Akrikos

1
"Une requête POST obtient une entrée de la chaîne de requête et du corps de la requête." À mon humble avis, c'est incorrect. Pour utiliser l'une ou l'autre entrée, vous devez utiliser $ _REQUEST. $ _POST n'obtient pas les entrées d'URL.
Gunnar Bernstein

1
@Frank Schwieterman Je sais que ce message est ancien, mais supprimer mon compte n'est pas idempotent et ne devrait pas utiliser get.
frostymarvelous

77

Lorsque l'utilisateur saisit des informations dans un formulaire et clique sur Envoyer, les informations peuvent être envoyées du navigateur au serveur de deux manières: dans l'URL ou dans le corps de la demande HTTP.

La méthode GET, utilisée dans l'exemple précédent, ajoute des paires nom / valeur à l'URL. Malheureusement, la longueur d'une URL est limitée, donc cette méthode ne fonctionne que s'il n'y a que quelques paramètres. L'URL peut être tronquée si le formulaire utilise un grand nombre de paramètres ou si les paramètres contiennent de grandes quantités de données. De plus, les paramètres transmis à l'URL sont visibles dans le champ d'adresse du navigateur et non le meilleur endroit pour afficher un mot de passe.

L'alternative à la méthode GET est la méthode POST. Cette méthode regroupe les paires nom / valeur dans le corps de la requête HTTP, ce qui permet une URL plus propre et n'impose aucune limitation de taille sur la sortie des formulaires. Il est également plus sûr.


1
Comment est-il plus «sécurisé»?
Julian Reschke

4
parce que c'est plus difficile à changer? vous pouvez changer GET dans la barre d'adresse, mais ce n'est pas si simple avec POST.
IAdapter

8
Le serveur ne peut pas faire confiance au client. Concevoir votre application autour de fausses hypothèses, est loin d'être sécurisé.
troelskn

openid n'est pas non plus enregistré, car il peut être cassé?
IAdapter

1
Je pense que c'est l'explication la plus claire - la différence sur le placement des données envoyées. Je vous remercie.
greenoldman

37

La meilleure réponse a été la première.

Vous utilisez:

  • GET lorsque vous souhaitez récupérer des données (GET DATA).
  • POST lorsque vous souhaitez envoyer des données (POST DATA).

2
Quel modèle de service de demande / réponse est utilisé et que vous souhaitez faire les deux? ;) Je préférerais utiliser POST dans la plupart des cas lorsque j'ai besoin d'avoir une réponse.
Dmitry Pavlov

8
C'est généralement vrai. GETest parfaitement capable d'envoyer des données aussi, donc ce n'est pas une réponse très précise.
Patrick Hofman

23

Il y a deux implications communes de «sécurité» à l'utilisation GET. Étant donné que les données apparaissent dans la chaîne d'URL, il se peut que quelqu'un qui regarde par-dessus votre épaule dans la barre d'adresse / URL puisse voir quelque chose auquel il ne devrait pas avoir accès, comme un cookie de session qui pourrait potentiellement être utilisé pour détourner votre session. Gardez à l'esprit que tout le monde a des téléphones-appareils photo.

L'autre implication de sécurité GETconcerne les GETvariables enregistrées dans la plupart des journaux d'accès des serveurs Web dans le cadre de l'URL demandeuse. Selon la situation, le climat réglementaire et la sensibilité générale des données, cela peut potentiellement susciter des inquiétudes.

Certains clients / pare-feu / systèmes IDS peuvent désapprouver les GETdemandes contenant une quantité excessive de données et peuvent donc fournir des résultats peu fiables.

POST prend en charge des fonctionnalités avancées telles que la prise en charge de l'entrée binaire en plusieurs parties utilisée pour les téléchargements de fichiers sur les serveurs Web.

POSTnécessite un en-tête de longueur de contenu qui peut augmenter la complexité d'une implémentation client spécifique à l'application, car la taille des données soumises doit être connue à l'avance pour empêcher qu'une demande client ne soit formée dans un mode incrémentiel à passage unique. Peut-être un problème mineur pour ceux qui choisissent d'abuser HTTPen l'utilisant comme transport RPC (Remote Procedure Call).

D'autres ont déjà fait un bon travail en couvrant les différences sémantiques et la partie «quand» de cette question.


17

J'utilise GET lorsque je récupère des informations d' une URL et POST lorsque j'envoie des informations vers une URL.


1
mais vous pouvez également utiliser GET pour envoyer. La différence est le format (dans l'url (GET) ou dans la requête (POST)).
eric

Si le point de terminaison accepte un fichier et renvoie une ligne à partir du fichier (aucune création ou modification de données ou base de données n'est impliquée), le point de terminaison doit-il être GET ou POST?
variable

17

Vous devriez utiliser POST s'il y a beaucoup de données ou trier des informations sensibles (les choses vraiment sensibles ont également besoin d'une connexion sécurisée).

Utilisez GET si vous souhaitez que les utilisateurs puissent mettre votre page en signet, car toutes les données sont incluses avec le signet.

Faites juste attention aux personnes qui frappent REFRESH avec la méthode GET, car les données seront envoyées à nouveau à chaque fois sans avertir l'utilisateur (POST avertit parfois l'utilisateur de renvoyer des données).


Si le point de terminaison accepte un fichier et renvoie une ligne à partir du fichier (aucune création ou modification de données ou base de données n'est impliquée), le point de terminaison doit-il être GET ou POST?
variable

@variable POST. Dans ce cas, principalement parce que POST est conçu pour gérer les téléchargements de fichiers et que GET standard ne l'est pas. Vous devez envoyer le fichier à chaque chargement de la page, il est donc logique d'utiliser simplement le POST standard au lieu du fichier GET +, ce qui briserait l'attente de GET qu'une URL devrait donner plus ou moins les mêmes résultats à chaque fois.
Accordez

14

Ce document du W3C explique l'utilisation de HTTP GET et POST.

Je pense que c'est une source faisant autorité.

Le résumé est (section 1.3 du document):

  • Utilisez GET si l'interaction ressemble plus à une question (c'est-à-dire qu'il s'agit d'une opération sûre telle qu'une requête, une opération de lecture ou une recherche).
  • Utilisez POST si:
    • L'interaction ressemble plus à une commande, ou
    • L'interaction modifie l'état de la ressource d'une manière que l'utilisateur percevrait (par exemple, un abonnement à un service), ou
    • L'utilisateur doit être tenu responsable des résultats de l'interaction.

9
Je pense que cela peut être résumé comme suit: GET lorsque l'état du serveur n'est pas modifié, POST lorsqu'il l'est.
Yamcha

10

Les méthodes Get et Post n'ont rien à voir avec la technologie de serveur que vous utilisez, elles fonctionnent de la même manière sur php, asp.net ou ruby. GET et POST font partie du protocole HTTP. Comme l'a noté Mark, POST est plus sécurisé. Les formulaires POST ne sont pas non plus mis en cache par le navigateur. POST est également utilisé pour transférer de grandes quantités de données.


8

La raison d'utiliser POST lors de la modification des données:

  • Un accélérateur Web comme Google Web Accelerator cliquera sur tous les liens (GET) sur une page et les mettra en cache. C'est très mauvais si les liens apportent des modifications aux choses.
  • Un navigateur met en cache les requêtes GET, donc même si l'utilisateur clique sur le lien, il ne peut pas envoyer de requête au serveur pour exécuter la modification.
  • Pour protéger votre site / application contre CSRF, vous devez utiliser POST. Pour sécuriser complètement votre application, vous devez également générer un identifiant unique sur le serveur et l'envoyer dans la demande.

De plus, ne mettez pas d'informations sensibles dans la chaîne de requête (uniquement option avec GET) car elles apparaissent dans la barre d'adresse, les signets et les journaux du serveur.

J'espère que cela explique pourquoi les gens disent que le POST est «sécurisé». Si vous transmettez des données sensibles, vous devez utiliser SSL.


8

GETet POSTsont des méthodes HTTP qui peuvent atteindre des objectifs similaires

GETest essentiellement pour obtenir (récupérer) des données, A GETne devrait pas avoir de corps, donc à part les cookies, le seul endroit pour transmettre des informations est dans l'URL et les URL sont de longueur limitée, GETsont moins sécurisées que POSTparce que les données envoyées font partie de l'URL

Ne jamais utiliser GETlors de l'envoi de mots de passe, de carte de crédit ou d'autres informations sensibles !, Les données sont visibles par tous dans l'URL, peuvent être des données mises en cache. GETest inoffensif lorsque nous rechargeons ou rappelons le bouton, il sera marqué d'un livre, les paramètres restent dans l'historique du navigateur, seuls les caractères ASCII sont autorisés.

POSTpeut impliquer quoi que ce soit, comme le stockage ou la mise à jour des données, ou la commande d'un produit, ou l'envoi d'e-mails. POSTméthode a un corps.

POSTLa méthode est sécurisée pour transmettre des informations sensibles et confidentielles au serveur, elle ne sera pas visible dans les paramètres de requête dans l'URL et les paramètres ne sont pas enregistrés dans l'historique du navigateur. Il n'y a aucune restriction sur la longueur des données. Lorsque nous rechargeons, le navigateur doit avertir l'utilisateur que les données sont sur le point d'être soumises à nouveau. POSTla méthode ne peut pas être mise en signet


3
  1. La méthode GET est utilisée pour envoyer les données moins sensibles tandis que la méthode POST est utilisée pour envoyer les données sensibles.
  2. En utilisant la méthode POST, vous pouvez envoyer une grande quantité de données par rapport à la méthode GET.
  3. Les données envoyées par la méthode GET sont visibles dans la barre d'en-tête du navigateur tandis que les données envoyées par la méthode POST sont invisibles.

0

Utilisez la méthode GET si vous souhaitez récupérer les ressources de l'URL. Vous pouvez toujours voir la dernière page si vous appuyez sur le bouton de retour de votre navigateur, et elle peut être mise en signet, elle n'est donc pas aussi sécurisée que la méthode POST.

Utilisez la méthode POST si vous souhaitez «soumettre» quelque chose à l'URL. Par exemple, vous souhaitez créer un compte Google et vous devrez peut-être remplir toutes les informations détaillées, puis vous appuyez sur le bouton «Soumettre» (la méthode POST est appelée ici), une fois que vous avez soumis avec succès, et essayez d'appuyer sur le bouton de retour de votre navigateur , vous obtiendrez une erreur ou un nouveau formulaire vierge, au lieu de la dernière page avec le formulaire rempli.


-10

La GETméthode:

  • Il est utilisé uniquement pour envoyer une date de 256 caractères

  • Lorsque vous utilisez cette méthode, les informations peuvent être consultées sur le navigateur

  • C'est la méthode par défaut utilisée par les formulaires

  • Ce n'est pas si sûr.


La POSTméthode:

  • Il est utilisé pour envoyer des données illimitées.

  • Avec cette méthode, les informations ne sont pas visibles sur le navigateur

  • Vous pouvez mentionner explicitement la POSTméthode

  • Il est plus sécurisé que la GETméthode

  • Il fournit des fonctionnalités plus avancées


"Il est utilisé uniquement pour envoyer une date de 256 caractères" - pas vrai. "Lorsque vous utilisez cette méthode, les informations peuvent être vues sur le navigateur" - les données de publication sont également visibles dans les navigateurs, ce n'est tout simplement pas si évident. "Il fournit des fonctionnalités plus avancées" - comme?
Quentin

Ce n'est pas une réponse terriblement utile. Des informations incorrectes telles que «ce n'est pas si sécurisé» et «fournit des fonctionnalités plus avancées», et d'autres choses mentionnées par Quentin.
Andrew Barber,
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.