Quand utilisez-vous POST et quand utilisez-vous GET?


344

D'après ce que je peux rassembler, il existe trois catégories:

  1. Ne jamais utiliser GETet utiliserPOST
  2. Ne jamais utiliser POSTet utiliserGET
  3. Peu importe celui que vous utilisez.

Ai-je raison de supposer ces trois cas? Si oui, quels sont les exemples de chaque cas?


1
Ce n'est en fait absolument pas vrai. GET et POST sont tous deux visibles dans la même mesure, si vous consultez les en-têtes envoyés par votre navigateur, vous verrez une liste des paires clé-valeur que vous publiez
Velimir Tchatchevsky


1
Il n'y a pas de moyen standard d'encoder plus que des paires nom -> valeur dans des chaînes de requête, donc à moins que vos demandes soient très basiques (c'est-à-dire pas de tableaux ou de structures de données imbriquées), vous ne devriez considérer que POST qui fournit un champ de corps que vous pouvez utiliser avec les formats d'encodage (JSON, XML, etc.).
themihai

Réponses:


377

Utilisez POSTpour des actions destructrices telles que la création (je suis conscient de l'ironie), l'édition et la suppression, car vous ne pouvez pas frapper une POSTaction dans la barre d'adresse de votre navigateur. À utiliser GETen toute sécurité pour permettre à une personne d'appeler une action. Donc une URL comme:

http://myblog.org/admin/posts/delete/357

Devrait vous amener à une page de confirmation, plutôt que de simplement supprimer l'élément. Il est beaucoup plus facile d'éviter les accidents de cette façon.

POSTest également plus sûr que GET, car vous ne collez pas d'informations dans une URL. Et donc utiliser GETcomme methodun formulaire HTML qui recueille un mot de passe ou d'autres informations sensibles n'est pas la meilleure idée.

Une dernière remarque: POSTpeut transmettre une plus grande quantité d'informations que GET. 'POST' n'a pas de restrictions de taille pour les données transmises, tandis que 'GET' est limité à 2048 caractères.


83
Les réponses aux demandes GET peuvent être cahées. Les réponses aux POST ne doivent pas.
mkoeller

31
Comment le fait de ne pas coller d'informations dans l'URL ne les rend-il pas plus sécuritaires? (Btw, je suis de ceux qui croient qu'un faux sentiment de sécurité est plus dangereux que de ne pas avoir de sécurité du tout).
ePharaoh

42
@ePharaoh: Cela empêche les gens de lire les mots de passe en regardant par-dessus l'épaule des utilisateurs dans la barre d'adresse.
Quentin

35
@ePharaoh: "Exposer un peu moins de données à un observateur occasionnel" serait probablement une meilleure formulation que "plus sûr" - les URL peuvent se retrouver à de nombreux endroits, comme les journaux, les référents, les caches. Vous avez bien sûr raison, cela n'augmente pas la sécurité - mais cela limite les pires pratiques non sécurisées (voir aussi: thedailywtf.com/Articles/The_Spider_of_Doom.aspx )
Piskvor a quitté le bâtiment le

24
@David Dorward: Ou par son nom plus commun: attaque à l'épaule
Idan K

206

En bref

  • Utilisation GETpour les safe andidempotentdemandes
  • Utilisation POSTpour les neither safe nor idempotentdemandes

En détail Il y a une place appropriée pour chacun. Même si vous ne suivez pas les principes RESTful , vous pouvez gagner beaucoup en apprenant sur REST et sur le fonctionnement d'une approche orientée ressources.

Une application RESTful sera use GETspour les opérations qui sont les deux safe and idempotent.

Une safeopération est une opération qui ne not change the datademande.

Une idempotentopération est une opération dans laquelle le résultat, be the samepeu importe le nombre de fois que vous le demanderez.

Il va de soi que, comme les GET sont utilisés pour des opérations sûres , ils sont automatiquement également idempotents . Généralement, un GET est utilisé pour récupérer une ressource (une question et ses réponses associées lors d'un débordement de pile par exemple) ou une collection de ressources.

Une application RESTful utilisera PUTspour les opérations qui le sont not safe but idempotent.

Je sais que la question portait sur GET et POST, mais je reviendrai sur POST dans une seconde.

Typiquement, un PUT est utilisé pour éditer une ressource (éditer une question ou une réponse sur débordement de pile par exemple).

Un POSTserait utilisé pour toute opération qui l'est neither safe or idempotent.

En règle générale, un POST serait utilisé pour créer une nouvelle ressource, par exemple en créant une nouvelle question SO (bien que dans certains modèles, un PUT soit également utilisé pour cela).

Si vous exécutez le POST deux fois, vous finirez par créer DEUX nouvelles questions.

Il y a aussi une opération DELETE, mais je suppose que je peux laisser ça là :)

Discussion

En termes pratiques, les navigateurs Web modernes ne prennent généralement en charge que GET et POST de manière fiable (vous pouvez effectuer toutes ces opérations via des appels javascript, mais en termes de saisie de données dans les formulaires et de validation, vous avez généralement les deux options). Dans une application RESTful, le POST sera souvent remplacé pour fournir également les appels PUT et DELETE.

Mais, même si vous ne suivez pas les principes RESTful, il peut être utile de penser en termes d'utilisation de GET pour récupérer / afficher des informations et POST pour créer / modifier des informations.

Vous ne devez jamais utiliser GET pour une opération qui modifie des données. Si un moteur de recherche explore un lien vers votre mauvaise opération ou les signets du client, cela pourrait causer de gros problèmes.


si vous créez une ressource APIREST pour la connexion que vous choisirez, c'est sûr et idempotent, je l'invite.
jhonny lopez

1
Un get sûr n'est pas automatiquement idempotent. Le jeu de résultats peut être différent avec la même requête non destructive.
RichieHH

1
La façon dont vous l'avez écrit, quelque chose comme "GET currenttime" serait erronée car elle n'est pas idempotente (dans le sens où des requêtes répétées peuvent produire des résultats différents); en fait, tout ce qui est demandé peut changer avec le temps. Il faut donc exprimer l'idempotence plutôt en termes d' effets secondaires de la requête elle-même. Étant donné que le simple fait de demander l'heure actuelle n'a aucun effet secondaire , il s'agit - comme on pourrait s'y attendre - d'un candidat parfait pour GET et non pour POST.
Hagen von Eitzen

79

Utilisez GET si cela ne vous dérange pas que la demande soit répétée (c'est-à-dire qu'elle ne change pas d'état).

Utilisez POST si l'opération modifie l'état du système.


1
Puisqu'un formulaire modifie l'état du système, pourquoi la méthode par défaut de la balise de formulaire HTML est GET?
ziiweb

3
@ user248959 Un champ de recherche modifie-t-il l'état visible? La valeur par défaut a été définie il y a longtemps, probablement presque par accident. Je n'ai pas fouillé dans l'histoire pour même savoir si le POST était une option au moment où les formulaires étaient une option.
Douglas Leeder

@ziiweb Même si la majorité des cas d'utilisation de <form> est POST, il est préférable de définir le dafault comme un GET "inoffensif". Cela peut sembler absurde du point de vue de la sécurité quand cela conduit à des données exposées dans des fichiers journaux, etc., mais c'est sûr en ce qui concerne les données côté serveur (le serveur ne doit pas modifier les données lors d'un GET). Je suppose que l'on fixerait le focus différemment aujourd'hui (de préférence en supprimant toute valeur par défaut et en la rendant methodobligatoire)
Hagen von Eitzen

Supposons que j'ai un point de terminaison qui accepte un fichier en entrée, effectue un traitement sur le fichier (exemple - extraire des données basées sur l'expression régulière) et renvoie des données JSON, puis-je utiliser la demande GET pour télécharger un fichier sur le serveur. Ou dois-je utiliser la demande POST?
variable

67

Version courte

OBTENIR: généralement utilisé pour les demandes de recherche soumises, ou toute demande pour laquelle l'utilisateur souhaite pouvoir afficher à nouveau la page exacte.

Avantages de GET:

  • Les URL peuvent être mises en signet en toute sécurité.
  • Les pages peuvent être rechargées en toute sécurité.

Inconvénients de GET:

POST: utilisé pour les demandes de sécurité plus élevées où les données peuvent être utilisées pour modifier une base de données ou une page que vous ne souhaitez pas que quelqu'un marque en signet.

Avantages de POST:

  • Les paires nom-valeur ne sont pas affichées dans l'URL. (Sécurité + = 1)
  • Un nombre illimité de paires nom-valeur peut être transmis via POST. Référence.

Inconvénients de POST:

  • La page qui a utilisé des données POST ne peut pas être un signet. (Si vous le souhaitez.)

Version plus longue

Directement à partir du protocole de transfert hypertexte - HTTP / 1.1 :

9.3 OBTENIR

La méthode GET signifie récupérer toutes les informations (sous la forme d'une entité) identifiées par l'URI de demande. Si l'URI de demande fait référence à un processus de production de données, ce sont les données produites qui doivent être renvoyées en tant qu'entité dans la réponse et non le texte source du processus, sauf si ce texte se trouve être la sortie du processus.

La sémantique de la méthode GET devient un "GET conditionnel" si le message de demande comprend un champ d'en-tête If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match ou If-Range. Une méthode GET conditionnelle demande que l'entité soit transférée uniquement dans les circonstances décrites par le ou les champs d'en-tête conditionnels. La méthode GET conditionnelle est destinée à réduire l'utilisation inutile du réseau en permettant aux entités mises en cache d'être actualisées sans nécessiter plusieurs demandes ou transférer des données déjà détenues par le client.

La sémantique de la méthode GET passe à un "GET partiel" si le message de demande comprend un champ d'en-tête Range. Un GET partiel demande que seule une partie de l'entité soit transférée, comme décrit dans la section 14.35. La méthode GET partielle est destinée à réduire l'utilisation inutile du réseau en permettant aux entités partiellement récupérées de se terminer sans transférer les données déjà détenues par le client.

La réponse à une demande GET peut être mise en cache si et seulement si elle répond aux exigences de mise en cache HTTP décrites dans la section 13.

Voir la section 15.1.3 pour les considérations de sécurité lors de l'utilisation pour les formulaires.

9.5 POST

La méthode POST est utilisée pour demander que le serveur d'origine accepte l'entité incluse dans la demande en tant que nouveau subordonné de la ressource identifiée par l'URI de demande dans la ligne de demande. POST est conçu pour permettre à une méthode uniforme de couvrir les fonctions suivantes:

  • Annotation des ressources existantes;

  • Publier un message sur un babillard, un groupe de discussion, une liste de diffusion ou un groupe d'articles similaire;

  • Fournir un bloc de données, comme le résultat de la soumission d'un formulaire, à un processus de traitement des données;

  • Extension d'une base de données via une opération d'ajout.

La fonction réelle exécutée par la méthode POST est déterminée par le serveur et dépend généralement de l'URI de demande. L'entité publiée est subordonnée à cet URI de la même manière qu'un fichier est subordonné à un répertoire qui le contient, un article de presse est subordonné à un groupe de discussion auquel il est publié ou un enregistrement est subordonné à une base de données.

L'action effectuée par la méthode POST peut ne pas aboutir à une ressource qui peut être identifiée par un URI. Dans ce cas, 200 (OK) ou 204 (Pas de contenu) est le statut de réponse approprié, selon que la réponse inclut ou non une entité qui décrit le résultat.


2
"La page qui utilise les données de publication ne peut pas être mise en signet": eh bien, c'est un avantage, non? Vous ne voulez probablement pas que votre requête de modification de données soit mise en signet.
Piskvor a quitté le bâtiment le

Je suppose que si chaque fois que le message était utilisé, vous l'utilisiez à des fins de sécurité, ce serait un avantage. C'est généralement le cas, mais il y a cette limite de longueur sur GET. Peut-être que quelqu'un passe juste une tonne de données non liées à la sécurité et souhaite que la page soit mise en signet? Qui sait ...
Cimplicity

En ce qui concerne un inconvénient de GET, à savoir que "les variables sont transmises via l'URL en tant que paires nom-valeur", MVC éliminerait-il ce problème en raison du routage et des URL conviviales résultantes?
MrBoJangles

@MrBoJangles: L'utilisation de belles URL n'empêche pas le risque de «personne regardant par-dessus l'épaule» évoqué. Note latérale: MVC ne nécessite pas de routage avec de belles URL et le routage avec de belles URL ne nécessite pas de MVC; ils sont parfois utilisés ensemble, mais peuvent également être utilisés séparément.
icktoofay

Dans le monde .NET, à toutes fins pratiques, belle capacité d'url = MVC. Je suppose que vous pourriez faire des réécritures IIS ou des bizarres basées sur du code, mais elles sont encore moins agréables. MVC, inutile de dire, pour la victoire.
MrBoJangles

28

La première chose importante est la signification de GET par rapport à POST:

  • GET devrait être utilisé pour ... obtenir ... des informations du serveur,
  • tandis que POST doit être utilisé pour envoyer des informations au serveur.


Après cela, deux ou trois choses qui peuvent être notées:

  • En utilisant GET, vos utilisateurs peuvent utiliser le bouton "retour" dans leur navigateur et ils peuvent ajouter des pages aux favoris
  • Il y a une limite dans la taille des paramètres que vous pouvez passer en tant que GET (2 Ko pour certaines versions d'Internet Explorer, si je ne me trompe pas) ; la limite est beaucoup plus pour POST, et dépend généralement de la configuration du serveur.


Quoi qu'il en soit, je ne pense pas que nous pourrions "vivre" sans GET: pensez au nombre d'URL que vous utilisez avec des paramètres dans la chaîne de requête, chaque jour - sans GET, tout cela ne fonctionnerait pas ;-)


Eh bien, si tout le monde utilisait de jolies urls dans un style GET: http://example.com/var1/value1/var2/value2/var3/value3nous pourrions "techniquement" ne plus avoir GET ...
Tyler Carter

5
@ Chacha102 Sauf que vous devez encore OBTENIR cette ressource. Presque toutes les pages, images, scripts, etc. sont chargés dans les navigateurs Web à l'aide de GET.
Ryan

3
@ Chacha102 - Même les www.mypage.com/contact/utilisations GET en interne pour quelque chose commeindex.php?url=/contact/
Thiago Belem

1
Accent sur la taille limite de GET! De plus, les paramètres GET sont inclus dans les signets, contrairement à POST. Et, l'utilisateur peut actualiser une page demandée par GET, mais pas une page demandée par POST (sans avertissement de renvoi des informations).
Ricket

12

Outre la différence de contraintes de longueur dans de nombreux navigateurs Web, il existe également une différence sémantique. Les GET sont censés être «sûrs» dans la mesure où ce sont des opérations en lecture seule qui ne modifient pas l'état du serveur. Les POST changeront généralement d'état et donneront des avertissements sur la nouvelle soumission. Les robots d'indexation des moteurs de recherche peuvent faire des GET mais ne devraient jamais faire de POST.

Utilisez GET si vous souhaitez lire des données sans changer d'état et utilisez POST si vous souhaitez mettre à jour l'état sur le serveur.


+1. C'est la principale différence conceptuelle par rapport au rfc dont tout le reste découle. w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
Frank Farmer

8

Ma règle générale consiste à utiliser Get lorsque vous faites des requêtes au serveur qui ne vont pas changer d'état. Les publications sont réservées aux demandes au serveur qui modifient l'état.


8

Une différence pratique est que les navigateurs et les serveurs Web ont une limite sur le nombre de caractères pouvant exister dans une URL. C'est différent d'une application à l'autre, mais il est certainement possible de le toucher si vous avez des textareas dans vos formulaires.

Un autre problème avec les GET - ils sont indexés par les moteurs de recherche et autres systèmes automatiques. Google avait un jour un produit qui récupérait les liens sur la page que vous consultiez, ils seraient donc plus rapides à charger si vous cliquiez sur ces liens. Cela a causé des ravages majeurs sur les sites qui avaient des liens comme delete.php?id=1- les gens ont perdu tous leurs sites.


1
Votre serveur Web a probablement aussi des limites à cela.
Billy ONeal

Eh bien, il y a aussi une limite au POST.
chelmertz

1
Grand point, @BillyONeal, j'ai ajouté cela dans. @Chelmertz Oui, mais je peux changer cela si je veux, et c'est beaucoup plus élevé. J'ai POSÉ 1 fichier gigaoctet sur des instances Apache, par exemple.
ceejayoz

Je comprends que les URL sont indexées par les moteurs de recherche. Je ne comprends pas ce que cela a à voir avec GET. Je veux dire, n'est-ce pas une URL juste une URL?
Honey

1
Les moteurs de recherche @Honey suivent les liens. Les liens font des requêtes GET. Les moteurs de recherche ne soumettent pas de formulaires (s'ils le faisaient, vous verriez Google ouvrir un compte sur votre site tous les quelques jours) et donc ne faire aucune demande POST.
ceejayoz

7

Utilisez GET lorsque vous souhaitez que l'URL reflète l'état de la page. Ceci est utile pour afficher des pages générées dynamiquement, telles que celles vues ici. Un POST doit être utilisé dans un formulaire pour soumettre des données, comme lorsque je clique sur le bouton "Publier votre réponse". Il produit également une URL plus propre car il ne génère pas de chaîne de paramètres après le chemin.


6

Étant donné que les GET sont purement des URL, ils peuvent être mis en cache par le navigateur Web et peuvent être mieux utilisés pour des choses comme des images générées de manière cohérente. (Définir une heure d'expiration)

Un exemple de la page gravatar: http://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802?d=monsterid

GET peut améliorer légèrement les performances, certains serveurs Web écrivent le contenu POST dans un fichier temporaire avant d'appeler le gestionnaire.

Une autre chose à considérer est la limite de taille. Les GET sont limités par la taille de l'URL, 1024 octets par défaut, bien que les navigateurs puissent en prendre en charge davantage.

Transférer plus de données que cela devrait utiliser un POST pour obtenir une meilleure compatibilité du navigateur.

Encore moins que cette limite est un problème, comme l'a écrit une autre affiche, tout ce qui se trouve dans l'URL pourrait se retrouver dans d'autres parties de l'interface utilisateur du navigateur, comme l'histoire.


4

Il n'y a rien que vous ne puissiez pas faire en soi. Le fait est que vous n'êtes pas censé modifier l'état du serveur sur un HTTP GET. Les proxys HTTP supposent que, puisque HTTP GET ne modifie pas l'état, le fait qu'un utilisateur invoque HTTP GET une fois ou 1000 fois ne fait aucune différence. En utilisant ces informations, ils supposent qu'il est sûr de renvoyer une version mise en cache du premier HTTP GET. Si vous cassez la spécification HTTP, vous risquez de casser le client HTTP et les proxys dans la nature. Ne le fais pas :)


Ce ne sont pas seulement les navigateurs qui comptent sur GET pour être sûrs et idempotents: les araignées des moteurs de recherche et les navigateurs de prélecture (comme plus rapidefox) dépendent également de cela.
Frank Farmer

@gili, enfin quelqu'un avec une bonne réponse. Je suis vraiment surpris du nombre de personnes qui se sont trompées. pouces vers le haut!
lubos hasko

4

Cela traverse le concept de REST et la façon dont le Web était destiné à être utilisé. Il existe un excellent podcast sur la radio Software Engineering qui donne un exposé approfondi sur l'utilisation de Get et Post.

Get est utilisé pour extraire des données du serveur, où une action de mise à jour ne devrait pas être nécessaire. L'idée étant que vous devriez pouvoir utiliser la même demande GET encore et encore et avoir les mêmes informations retournées. L'URL contient les informations get dans la chaîne de requête, car elle était censée pouvoir être facilement envoyée à d'autres systèmes et à des personnes comme une adresse où trouver quelque chose.

Post est censé être utilisé (au moins par l'architecture REST sur laquelle le Web est un peu basé) pour pousser les informations vers le serveur / dire au serveur d'effectuer une action. Exemples tels que: mettre à jour ces données, créer cet enregistrement.


"Il existe un excellent podcast sur la radio Software Engineering qui donne un exposé approfondi sur l'utilisation de Get et Post." Où est-ce?
yeeen

J'y ai ajouté un lien.
kemiller2002

Voici ce lien: se-radio.net/2008/05/episode-98-stefan-tilkov-on-rest J'ai également édité le lien ci-dessus, même si je n'ai pas de droits d'édition et que ça doit être révisé par des pairs, etc.
MrBoJangles

Supposons que j'ai un point de terminaison qui accepte un fichier en entrée, effectue un traitement sur le fichier (exemple - extraire des données basées sur l'expression régulière) et renvoie des données JSON, puis-je utiliser la demande GET pour télécharger un fichier sur le serveur. Ou dois-je utiliser la demande POST?
variable

4

1.3 Liste de contrôle rapide pour choisir HTTP GETouPOST

Utilisez GET si:

    The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

Utilisez POST si:

    The interaction is more like an order, or
    The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
    The user be held accountable for the results of the interaction.

Source .


3

je ne vois pas de problème en utilisant get, je l'utilise pour des choses simples où il est logique de garder les choses sur la chaîne de requête.

L'utiliser pour mettre à jour l'état - comme un GET delete.php?id=5pour supprimer une page - est très risqué. Les gens l'ont découvert lorsque l'accélérateur Web de Google a commencé à précharger les URL sur les pages - il a frappé tous les liens de suppression et effacé les données des personnes. La même chose peut arriver avec les araignées des moteurs de recherche.



3

De RFC 2616 :

9.3 GET
La méthode GET signifie récupérer toutes les informations (sous la forme d'une entité) identifiées par l'URI de demande. Si l'URI de demande fait référence à un processus de production de données, ce sont les données produites qui doivent être renvoyées en tant qu'entité dans la réponse et non le texte source du processus, sauf si ce texte se trouve être la sortie du processus.


9.5 POST
La méthode POST est utilisée pour demander au serveur d'origine d'accepter l'entité incluse dans la demande en tant que nouveau subordonné de la ressource identifiée par l'URI de demande dans la ligne de demande. POST est conçu pour permettre à une méthode uniforme de couvrir les fonctions suivantes:

  • Annotation des ressources existantes;
  • Publier un message sur un babillard, un groupe de discussion, une liste de diffusion ou un groupe d'articles similaire;
  • Fournir un bloc de données, tel que le résultat de la soumission d'un formulaire, à un processus de traitement des données;
  • Extension d'une base de données via une opération d'ajout.

La fonction réelle exécutée par la méthode POST est déterminée par le serveur et dépend généralement de l'URI de demande. L'entité publiée est subordonnée à cet URI de la même manière qu'un fichier est subordonné à un répertoire qui le contient, un article de presse est subordonné à un groupe de discussion auquel il est publié ou un enregistrement est subordonné à une base de données.

L'action effectuée par la méthode POST peut ne pas aboutir à une ressource qui peut être identifiée par un URI. Dans ce cas, 200 (OK) ou 204 (Pas de contenu) est le statut de réponse approprié, selon que la réponse inclut ou non une entité qui décrit le résultat.


2

J'utilise POST lorsque je ne veux pas que les gens voient le QueryString ou lorsque le QueryString devient volumineux. En outre, POST est nécessaire pour les téléchargements de fichiers.

Je ne vois pas de problème en utilisant GET, je l'utilise pour des choses simples où il est logique de garder les choses sur QueryString.

L'utilisation de GET permettra également de créer un lien vers une page particulière où POST ne fonctionnerait pas.


Pourquoi ne pouvons-nous pas utiliser GET pour le téléchargement de fichiers?
variable

1

L'intention initiale était d'utiliser GET pour récupérer les données et POST devait être n'importe quoi. La règle générale que j'utilise est que si j'envoie quelque chose au serveur, j'utilise POST. Si j'appelle simplement une URL pour récupérer des données, j'utilise GET.


1

Lisez l' article sur HTTP dans Wikipedia . Il expliquera ce qu'est le protocole et ce qu'il fait:

AVOIR

Demande une représentation de la ressource spécifiée. Notez que GET ne doit pas être utilisé pour des opérations qui provoquent des effets secondaires, telles que son utilisation pour effectuer des actions dans des applications Web. L'une des raisons à cela est que GET peut être utilisé arbitrairement par des robots ou des robots, qui ne devraient pas avoir à prendre en compte les effets secondaires qu'une demande devrait provoquer.

et

POST Soumet les données à traiter (par exemple, à partir d'un formulaire HTML) à la ressource identifiée. Les données sont incluses dans le corps de la demande. Cela peut entraîner la création d'une nouvelle ressource ou la mise à jour des ressources existantes ou les deux.

Le W3C a un document nommé URI, adressabilité et l'utilisation de HTTP GET et POST qui explique quand utiliser quoi. En citant

1.3 Liste de contrôle rapide pour choisir HTTP GET ou POST

  • 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).

et

  • 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 o L'utilisateur soit tenu responsable des résultats de l'interaction.

Cependant, avant la décision finale d'utiliser HTTP GET ou POST, veuillez également tenir compte des considérations relatives aux données sensibles et des considérations pratiques.

Un exemple pratique serait chaque fois que vous soumettez un formulaire HTML. Vous spécifiez soit publier soit obtenir pour l'action de formulaire. PHP remplira $ _GET et $ _POST en conséquence.


1

En PHP, POSTla limite de données est généralement définie par votre php.ini. GETest limité par les paramètres du serveur / navigateur, je crois - généralement autour des 255octets.


1

De w3schools.com :

Qu'est-ce que HTTP?

Le protocole de transfert hypertexte (HTTP) est conçu pour permettre les communications entre les clients et les serveurs.

HTTP fonctionne comme un protocole de demande-réponse entre un client et un serveur.

Un navigateur Web peut être le client et une application sur un ordinateur qui héberge un site Web peut être le serveur.

Exemple: un client (navigateur) soumet une requête HTTP au serveur; puis le serveur renvoie une réponse au client. La réponse contient des informations d'état sur la demande et peut également contenir le contenu demandé.

Deux méthodes de requête HTTP: GET et POST

Deux méthodes couramment utilisées pour une demande-réponse entre un client et un serveur sont: GET et POST.

GET - Demande des données à une ressource spécifiée POST - Soumet des données à traiter à une ressource spécifiée

Nous distinguons ici les principales différences:

entrez la description de l'image ici


1
Il serait préférable que les chercheurs et les lecteurs saisissent le contenu de l'image dans la réponse. De plus, la première partie de la réponse n'aide pas vraiment à répondre à la question.
Dave Schweisguth

Copiez-collez à partir d' ici - vous devez citer correctement votre source et la licence de la source doit permettre la réutilisation, ce que je ne pense pas que w3schools fasse. En dehors de cela, pensez-vous vraiment que cela ajoute quelque chose qui n'était pas couvert dans les 25 autres réponses?
Benjamin W.

1

Version simple de POST GET PUT DELETE

  • utiliser GET - lorsque vous souhaitez obtenir une ressource comme une liste de données basée sur un identifiant ou un nom
  • utilisez POST - lorsque vous souhaitez envoyer des données au serveur. Gardez à l'esprit que POST est une opération lourde car pour la mise à jour, nous devons utiliser PUT au lieu de POST en interne. POST créera une nouvelle ressource
  • utilisez PUT - lorsque vous

4
"utilisez PUT - quand vous" Où est le reste de la phrase?
Pang

C'est génial que quelqu'un ait tellement aimé les deux premières puces de cette réponse qu'ils l'ont voté sans la dernière balle haha: '-)
pooley1994

0

Eh bien, une chose importante est que tout ce que vous soumettez GETsera exposé via l'URL. Deuxièmement, comme le dit Ceejayoz, il y a une limite de caractères pour une URL.


0

Une autre différence est que POST nécessite généralement deux opérations HTTP, alors que GET n'en requiert qu'une.

Edit: je dois clarifier - pour les modèles de programmation courants. Généralement, répondre à un POST avec une page Web HTML directe est une conception discutable pour diverses raisons, dont la gênante "vous devez soumettre à nouveau ce formulaire, le souhaitez-vous?" en appuyant sur le bouton de retour.


2
POST ne nécessite pas 2 opérations http.
Billy ONeal

3
post-redirect-get nécessite 2 opérations: en.wikipedia.org/wiki/Post/Redirect/Get
cherouvim

1
POST peut nécessiter 2 allers-retours vers le serveur - un modèle courant consiste à POST avec un en- expect: 100-continuetête, puis à n'envoyer des données qu'une fois que le serveur répond avec un 100 CONTINUE.
Frank Farmer

Bel article cherouvim, je n'ai jamais su que le patron avait un nom.
Plynx

@cherouvim: La redirection de publication est efficace, mais pas la publication ordinaire. Vous pouvez tout aussi simplement obtenir get redirect avec les mêmes résultats. Cela n'a rien à voir avec le protocole utilisé par votre formulaire pour la soumission.
Billy ONeal

0

Comme d'autres l'ont répondu, il y a une limite sur la taille de l'URL avec get, et les fichiers peuvent être soumis avec la publication uniquement.

Je voudrais ajouter que l'on peut ajouter des choses à une base de données avec un get et effectuer des actions avec un post. Lorsqu'un script reçoit un message ou un get, il peut faire tout ce que l'auteur veut qu'il fasse. Je crois que le manque de compréhension vient du libellé choisi par le livre ou de la façon dont vous le lisez.

Un auteur de script doit utiliser des publications pour modifier la base de données et utiliser get uniquement pour la récupération d'informations.

Les langages de script ont fourni de nombreux moyens pour accéder à la demande. Par exemple, PHP permet l'utilisation de $_REQUESTpour récupérer un article ou un get. Il faut éviter cela au profit des plus spécifiques $_GETou $_POST.

Dans la programmation Web, il y a beaucoup plus de place pour l'interprétation. Il y a ce que l'on doit et ce que l'on peut faire, mais lequel est le meilleur est souvent sujet à débat. Heureusement, dans ce cas, il n'y a pas d'ambiguïté. Vous devez utiliser les messages pour modifier les données, et vous devriez utiliser pour obtenir de récupérer des informations.


0

Gorgapor, mod_rewriteutilise encore souvent GET. Il permet simplement de traduire une URL plus conviviale en une URL avec une GETchaîne de requête.


-1

Les données HTTP Post n'ont pas de limite spécifiée sur la quantité de données, alors que différents navigateurs ont des limites différentes pour les GET. Le RFC 2068 déclare:

Les serveurs doivent être prudents en fonction des longueurs d'URI supérieures à 255 octets, car certaines anciennes implémentations client ou proxy peuvent ne pas prendre correctement en charge ces longueurs

Plus précisément, vous devez avoir les bonnes constructions HTTP pour leur utilisation. Les HTTP GET ne devraient pas avoir d'effets secondaires et peuvent être actualisés et stockés en toute sécurité par des proxy HTTP, etc.

Les POST HTTP sont utilisés lorsque vous souhaitez soumettre des données à une ressource URL.

Un exemple typique d'utilisation de HTTP GET se trouve dans une recherche, c'est-à-dire Search? Query = my + query Un exemple typique d'utilisation d'un HTTP POST consiste à envoyer des commentaires à un formulaire en ligne.

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.