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

De ce que je peux rassembler, il y a trois catégories:

  1. Ne jamais utiliser GET et utiliser POST
  2. Ne jamais utiliser POST et utiliser GET
  3. Peu importe lequel vous utilisez.

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

    Utilisez POST pour les actions destrucsortingces telles que la création (je suis conscient de l’ironie), l’édition et la suppression, car vous ne pouvez pas exécuter une action POST dans la barre d’adresse de votre navigateur. Utilisez GET quand il est sécuritaire de 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.

    POST est également plus sécurisé que GET , car vous ne collez pas d’informations dans une URL. Et donc, utiliser GET comme method pour un formulaire HTML qui recueille un mot de passe ou d’autres informations sensibles n’est pas la meilleure idée.

    Une dernière remarque: POST peut transmettre une plus grande quantité d’informations que GET . “POST” n’a pas de ressortingctions de taille pour les données transmises, alors que “GET” est limité à 2048 caractères.

    En bref

    • Utilisez GET pour safe and idempotent requêtes safe and idempotent
    • Utilisez POST pour neither safe nor idempotent demandes neither safe nor idempotent

    Dans les détails Il y a une place appropriée pour chacun. Même si vous ne suivez pas les principes de RESTful , vous pouvez tirer beaucoup de leçons de l’apprentissage de REST et du fonctionnement d’une approche axée sur les ressources.

    Une application RESTful use GETs pour les opérations à la fois safe and idempotent .

    Une opération safe est une opération qui ne not change the data demandées.

    Une opération idempotent est une opération dans laquelle le résultat sera be the same quel que soit le nombre de fois que vous le demandez.

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

    Une application RESTful utilisera les PUTs pour les opérations qui not safe but idempotent sont not safe but idempotent .

    Je sais que la question concernait GET et POST, mais je reviendrai à POST dans un instant.

    Généralement, un PUT est utilisé pour éditer une ressource (éditer une question ou une réponse sur un dépassement de stack par exemple).

    Un POST serait utilisé pour toute opération qui n’est neither safe or idempotent .

    Typiquement, 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é).

    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 supportent généralement 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 en appuyant sur soumettre, vous disposez généralement des 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 de RESTful, il peut être utile de penser à utiliser GET pour récupérer / afficher des informations et POST pour créer / éditer des informations.

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

    Utilisez GET si la requête ne se répète pas (cela ne change pas d’état).

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

    Version courte

    GET: Généralement utilisé pour les demandes de recherche soumises ou pour toute demande pour laquelle l’utilisateur doit 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:

    • Les variables sont passées via url en tant que paires nom-valeur. (Risque de sécurité)
    • Nombre limité de variables pouvant être transmises. (Basé sur le navigateur. Par exemple, Internet Explorer est limité à 2 048 caractères. )

    POST: Utilisé pour les demandes de sécurité plus élevées où les données peuvent être utilisées pour modifier une firebase database, ou une page que vous ne souhaitez pas qu’un signet de quelqu’un.

    Avantages du 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 du 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 GET

    La méthode GET signifie récupérer toute information (sous la forme d’une entité) identifiée 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 est la sortie du processus.

    La sémantique de la méthode GET passe à un “GET conditionnel” si le message de requête inclut 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 conditionnel. La méthode GET conditionnelle est destinée à réduire l’utilisation réseau inutile 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 requête inclut 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 d’être complétées sans transférer les données déjà détenues par le client.

    La réponse à une requête GET peut être mise en cache si et seulement si elle répond aux conditions requirejses pour la mise en cache HTTP décrites dans la section 13.

    Voir la section 15.1.3 pour les considérations de sécurité lorsqu’elles sont utilisées pour des 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. Le POST est conçu pour permettre à une méthode uniforme de couvrir les fonctions suivantes:

    • Annotation des ressources existantes;

    • Publier un message sur un tableau d’affichage, 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 firebase database 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 le contenant, un article d’actualité est subordonné à un groupe de discussion auquel il est publié ou un enregistrement est subordonné à une firebase database.

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

    La première chose importante est la signification de GET versus POST:

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

    Après cela, quelques choses peuvent être notées:

    • En utilisant GET, vos utilisateurs peuvent utiliser le bouton “retour” dans leur navigateur et ils peuvent append des pages aux favoris.
    • La taille des parameters que vous pouvez passer en tant que GET est limitée (2 Ko pour certaines versions d’Internet Explorer, si je ne me trompe pas) ; la limite est beaucoup plus pour le 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 parameters dans la chaîne de requête, tous les jours – sans GET, tout cela ne fonctionnerait pas 😉

    Outre la différence de longueur dans de nombreux navigateurs Web, il existe également une différence sémantique. Les GET sont supposés être “sûrs” en ce qu’ils sont en lecture seule et ne modifient pas l’état du serveur. Les POST changeront généralement d’état et donneront des avertissements lors de la nouvelle soumission. Les robots d’indexation des moteurs de recherche peuvent générer des GET mais ne doivent jamais effectuer 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 du serveur.

    Ma règle générale est d’utiliser Get lorsque vous faites des requêtes au serveur qui ne vont pas modifier l’état. Les messages sont réservés aux demandes adressées au serveur qui modifient l’état.

    Une différence pratique est que les navigateurs et les serveurs Web ont une limite quant au nombre de caractères pouvant exister dans une URL. C’est différent d’une application à l’autre, mais il est certainement possible d’y accéder si vous avez des textarea s dans vos formulaires.

    Un autre truc avec les GET – ils sont indexés par les moteurs de recherche et autres systèmes automatiques. Google a déjà eu un produit qui pré-extrait les liens sur la page que vous visualisiez, de sorte qu’ils seraient plus rapides à charger si vous cliquiez sur ces liens. Cela a causé des ravages importants sur les sites qui avaient des liens comme delete.php?id=1 – les gens ont perdu leurs sites entiers.

    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 dynamicment, telles que celles vues ici. Un POST devrait être utilisé sous une forme pour soumettre des données, comme lorsque je clique sur le bouton “Publiez votre réponse”. Il produit également une URL plus propre car il ne génère pas de chaîne de parameters après le chemin.

    Les GET étant purement des URL, ils peuvent être mis en cache par le navigateur Web et peuvent être mieux utilisés pour des choses telles que 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 présenter des performances légèrement supérieures, certains serveurs Web écrivent du contenu POST dans un fichier temporaire avant d’appeler le gestionnaire.

    Une autre chose à considérer est la taille limite. Les GET sont plafonnés par la taille de l’URL, 1024 octets par la norme, bien que les navigateurs puissent en supporter davantage.

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

    Même si 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’historique.

    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 proxies HTTP supposent que, puisque HTTP GET ne modifie pas l’état, le fait qu’un utilisateur appelle HTTP GET une fois ou 1000 fois ne fait aucune différence. En utilisant ces informations, ils supposent qu’il est prudent de renvoyer une version en cache du premier HTTP GET. Si vous cassez la spécification HTTP, vous risquez de casser le client HTTP et les proxies dans la nature. Ne le fais pas 🙂

    Cela se répercute sur le concept de REST et sur la manière dont le Web était destiné à être utilisé. Il y a un excellent podcast sur la radio de génie logiciel qui donne une discussion approfondie 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 requête GET à plusieurs resockets et obtenir les mêmes informations. L’URL a les informations get dans la chaîne de requête, car elle était destiné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 basé) pour transmettre des informations au serveur ou pour lui demander d’effectuer une action. Exemples: Mettre à jour ces données, Créer cet enregistrement.

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

    Utilisez GET si:

      The interaction is more like a question (ie, 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 (eg, a subscription to a service), or The user be held accountable for the results of the interaction. 

    Source

    Je ne vois pas de problème avec get cependant, 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 de delete.php?id=5 pour supprimer une page – est très risqué. Les gens ont découvert cela lorsque l’accélérateur Web de Google a commencé à récupérer les URL sur les pages – il a frappé tous les liens de suppression et a effacé les données des personnes. La même chose peut arriver avec les moteurs de recherche.

    POST peut déplacer de grandes données alors que GET ne le peut pas.

    Mais en règle générale, il ne s’agit pas d’un raccourci de GET, mais plutôt d’une convention si vous souhaitez que votre site Web / application Web se comporte bien.

    Jetez un oeil à http://www.w3.org/2001/tag/doc/whenToUseGet.html

    De RFC 2616 :

    9.3 GET
    La méthode GET signifie récupérer toute information (sous la forme d’une entité) identifiée 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 est la sortie du processus.

    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. Le POST est conçu pour permettre une méthode uniforme couvrant les fonctions suivantes:

    • Annotation des ressources existantes;
    • Publier un message sur un tableau d’affichage, 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 firebase database 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 le contenant, un article d’actualité est subordonné à un groupe de discussion auquel il est publié ou un enregistrement est subordonné à une firebase database.

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

    GET et POST permettent essentiellement de renvoyer des informations au serveur Web à partir d’un navigateur (ou d’un autre client HTTP).

    Imaginez que vous ayez un formulaire sur une page HTML et que vous cliquez sur le bouton “Envoyer” pour renvoyer les données du formulaire au serveur, sous la forme de paires “nom = valeur”.

    En choisissant GET comme “méthode”, vous appendez toutes les données à l’URL et elles apparaîtront dans la barre d’adresse de votre navigateur. La quantité d’informations que vous pouvez renvoyer en utilisant un GET est restreinte car les URL ne peuvent contenir que 1024 caractères.

    Les défis de l’intégration de l’informatique en nuage Télécharger maintenant Un POST, en revanche, enverra (généralement) les informations via un socket au serveur Web et il n’apparaîtra pas dans la barre d’URL. Vous pouvez envoyer beaucoup plus d’informations au serveur de cette manière – et cela ne se limite pas aux données textuelles non plus. Il est possible d’envoyer des fichiers et même des données binarys telles que des objects Java sérialisés!

    L’intention initiale était que GET était utilisé pour récupérer les données et que POST devait être n’importe quoi. La règle de base que j’utilise est que si je renvoie quelque chose au serveur, j’utilise POST. Si je ne fais qu’appeler une URL pour récupérer des données, j’utilise GET.

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

    OBTENIR

    Demande une représentation de la ressource spécifiée. Notez que GET ne doit pas être utilisé pour des opérations qui entraînent des effets secondaires, par exemple pour l’utilisation d’actions dans les applications Web. Une des raisons à cela est que GET peut être utilisé de manière arbitraire par des robots ou des robots d’exploration, ce qui ne devrait pas nécessiter de prendre en compte les effets secondaires qu’une demande devrait entraîner.

    et

    POST Soumet les données à traiter (par exemple, 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 les mises à jour des ressources existantes ou les deux.

    Le W3C a un document nommé URIs, Addressability et l’utilisation de HTTP GET et POST qui explique quand utiliser quoi. 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écurisée telle qu’une requête, une opération de lecture ou une recherche).

    et

    • Utilisez POST si:
      • L’interaction ressemble plus à un ordre, ou
      • L’interaction modifie l’état de la ressource de manière à ce que l’utilisateur puisse percevoir (par exemple, un abonnement à un service), ou • L’utilisateur soit tenu responsable des résultats de l’interaction.

    Cependant, avant de prendre la décision finale d’utiliser HTTP GET ou POST, veuillez également prendre en compte les considérations relatives aux données sensibles et aux considérations pratiques.

    Un exemple pratique serait chaque fois que vous soumettez un formulaire HTML. Vous spécifiez soit poster ou obtenir pour l’action de formulaire. PHP va remplir $ _GET et $ _POST en conséquence.

    En PHP, la limite de données POST est généralement définie par votre php.ini . Je pense que GET est limité par les parameters serveur / navigateur – généralement autour de 255 octets.

    J’utilise POST quand je ne veux pas que les gens voient le QuerySsortingng ou quand le QuerySsortingng devient grand. De plus, le POST est nécessaire pour les téléchargements de fichiers.

    Cependant, je ne vois pas de problème avec GET, je l’utilise pour des choses simples où il est logique de garder les choses sur le QuerySsortingng.

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

    Une version simple de POST GET PUT DELETE utilise GET – lorsque vous souhaitez obtenir une ressource comme List of data basée sur un Id ou Name, utilisez POST – lorsque vous souhaitez envoyer des données au serveur. Gardez à l’esprit que POST est une opération lourde car pour updation nous devrions utiliser PUT au lieu de POST en interne POST créera une nouvelle utilisation de ressource PUT – quand vous

    De w3schools.com :

    Qu’est-ce que HTTP?

    Le protocole HTTP (Hypertext Transfer Protocol) 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 hébergeant un site Web peut être le serveur.

    Exemple: un client (navigateur) envoie une requête HTTP au serveur; le serveur renvoie alors 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 à partir d’une ressource spécifiée POST – Soumet des données à traiter à une ressource spécifiée

    On distingue ici les différences majeures:

    entrer la description de l'image ici

    Une chose majeure est que tout ce que vous soumettez sur GET va être exposé via l’URL. Deuxièmement, comme le dit Ceejayoz, les caractères pour une URL sont limités.

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

    Edit: Je devrais clarifier – pour les modèles de programmation communs. Généralement, répondre à un POST avec une page Web HTML directe est une conception discutable pour une variété de raisons, dont l’une est ennuyante: «Vous devez soumettre à nouveau ce formulaire, souhaitez-vous le faire? en appuyant sur le bouton de retour.

    Comme répondu par d’autres, il y a une limite à la taille des URL avec get, et les fichiers peuvent être soumis avec post uniquement.

    J’aimerais append que l’on peut append des choses à une firebase database avec un get et effectuer des actions avec un post. Lorsqu’un script reçoit un message ou un get, il peut faire ce que l’auteur le souhaite. Je crois que le manque de compréhension vient du libellé choisi par le livre ou de sa lecture.

    Un auteur de script doit utiliser des messages pour modifier la firebase database et utiliser get uniquement pour récupérer des informations.

    Les langages de script ont fourni de nombreux moyens pour accéder à la requête. Par exemple, PHP permet d’utiliser $_REQUEST pour récupérer un article ou un message. On devrait éviter cela en faveur des $_GET ou $_POST plus spécifiques.

    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 on est souvent en train de débattre. Heureusement, dans ce cas, il n’y a pas d’ambiguïté. Vous devez utiliser les messages pour modifier les données, et vous devez utiliser get pour récupérer les informations.

    Gorgapor, mod_rewrite utilise encore souvent GET . Cela permet simplement de traduire une URL plus conviviale dans une URL avec une chaîne de requête GET .

    Les données de publication HTTP n’ont pas de limite spécifiée pour la quantité de données, alors que différents navigateurs ont des limites différentes pour les fichiers GET. Le RFC 2068 indique:

    Les serveurs doivent faire attention à ne pas dépendre des longueurs d’URI supérieures à 255 octets, car certaines implémentations de clients ou de proxy plus anciens peuvent ne pas prendre correctement en charge ces longueurs.

    Spécifiquement, vous devriez avoir les bonnes constructions HTTP pour ce pour quoi elles sont utilisées. Les HTTP GET ne devraient pas avoir d’effets secondaires et peuvent être actualisés et stockés en toute sécurité par les proxy HTTP, etc.

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

    Un exemple typique d’utilisation de HTTP GET est une recherche, c.-à-d. Une requête? Query = my + query Un exemple typique d’utilisation d’un protocole HTTP POST consiste à envoyer des commentaires à un formulaire en ligne.