Réponse courte: dans les requêtes POST, les valeurs sont envoyées dans le "corps" de la requête. Avec les formulaires Web, ils sont très probablement envoyés avec un type de support application/x-www-form-urlencoded
ou multipart/form-data
. Les langages de programmation ou des cadres qui ont été conçus pour gérer les requêtes web ne sont généralement « The Right Thing ™ » avec ces demandes et vous fournir un accès facile aux valeurs facilement décodés (comme $_REQUEST
ou $_POST
en PHP, ou cgi.FieldStorage()
, flask.request.form
en Python).
Maintenant, nous allons nous éloigner un peu, ce qui peut aider à comprendre la différence;)
La différence entre GET
et les POST
demandes sont largement sémantiques. Ils sont également «utilisés» différemment, ce qui explique la différence dans la façon dont les valeurs sont transmises.
Lors de l'exécution d'une GET
demande, vous en demandez une au serveur ou un ensemble d'entités. Pour permettre au client de filtrer le résultat, il peut utiliser la "chaîne de requête" de l'URL. La chaîne de requête est la partie après le ?
. Cela fait partie de la syntaxe URI .
Ainsi, du point de vue de votre code d'application (la partie qui reçoit la demande), vous devrez inspecter la partie de requête URI pour accéder à ces valeurs.
Notez que les clés et les valeurs font partie de l'URI. Les navigateurs peuvent imposer une limite à la longueur de l'URI. La norme HTTP indique qu'il n'y a pas de limite. Mais au moment où nous écrivons ces lignes, la plupart des navigateurs ne limitent les URIs (je n'ai pas de valeurs spécifiques). GET
les demandes ne doivent jamais être utilisées pour soumettre de nouvelles informations au serveur. Surtout pas des documents plus volumineux. C'est là que vous devez utiliser POST
ou PUT
.
Lors de l'exécution d'une POST
demande, le client soumet en fait un nouveau document à l'hôte distant. Ainsi, une chaîne de requête n'a pas (sémantiquement) de sens. C'est pourquoi vous n'y avez pas accès dans votre code d'application.
POST
est un peu plus complexe (et beaucoup plus flexible):
Lors de la réception d'une demande POST, vous devez toujours vous attendre à une "charge utile" ou, en termes HTTP: un corps de message . Le corps du message en lui-même est assez inutile, car il n'y a pas de format standard (pour autant que je sache. Peut-être application / octet-stream?). Le format du corps est défini par l'en- Content-Type
tête. Lorsque vous utilisez un FORM
élément HTML avec method="POST"
, c'est généralement le cas application/x-www-form-urlencoded
. Un autre type très courant est le multipart / form-data si vous utilisez des téléchargements de fichiers. Mais cela pourrait être n'importe quoi , allant de text/plain
, au-dessus application/json
ou même une coutume application/octet-stream
.
Dans tous les cas, si une POST
demande est faite avec un Content-Type
qui ne peut pas être traité par l'application, elle doit renvoyer un 415
code d'état .
La plupart des langages de programmation (et / ou cadres Web) offrent un moyen de dé / coder le corps du message de / vers les types les plus courants (comme application/x-www-form-urlencoded
, multipart/form-data
ou application/json
). C'est donc simple. Les types personnalisés nécessitent potentiellement un peu plus de travail.
En utilisant un document codé de formulaire HTML standard comme exemple, l'application doit effectuer les étapes suivantes:
- Lire le
Content-Type
terrain
- Si la valeur n'est pas l'un des types de supports pris en charge, retournez une réponse avec un
415
code d'état
- sinon, décodez les valeurs du corps du message.
Encore une fois, des langages comme PHP ou des frameworks Web pour d'autres langages populaires s'en occuperont probablement pour vous. L'exception à cela est l' 415
erreur. Aucun cadre ne peut prédire les types de contenu que votre application choisit de prendre en charge et / ou de ne pas prendre en charge. C'est à toi de décider.
Une PUT
demande est à peu près traitée de la même manière qu'une POST
demande. La grande différence est qu'une POST
demande est censée laisser le serveur décider comment (et le cas échéant) créer une nouvelle ressource. Historiquement (à partir de la RFC2616 désormais obsolète, il s'agissait de créer une nouvelle ressource en tant que "subordonné" (enfant) de l'URI où la demande a été envoyée).
Une PUT
demande en revanche est censée «déposer» une ressource exactement à cet URI, et avec exactement ce contenu. Ni plus ni moins. L'idée est que le client est responsable de créer la ressource complète avant de la "METTRE". Le serveur doit l'accepter tel quel sur l'URL donnée.
Par conséquent, une POST
demande n'est généralement pas utilisée pour remplacer une ressource existante. Une PUT
demande peut à la fois créer et remplacer.
Side-Note
Il existe également des " paramètres de chemin " qui peuvent être utilisés pour envoyer des données supplémentaires à la télécommande, mais ils sont si rares que je n'entrerai pas dans trop de détails ici. Mais, pour référence, voici un extrait du RFC:
Mis à part les segments de points dans les chemins hiérarchiques, un segment de chemin est considéré comme opaque par la syntaxe générique. Les applications produisant des URI utilisent souvent les caractères réservés autorisés dans un segment pour délimiter des sous-composants spécifiques au schéma ou au gestionnaire de déréférence. Par exemple, les points réservés point-virgule (";") et égal ("=") sont souvent utilisés pour délimiter les paramètres et les valeurs de paramètre applicables à ce segment. Le caractère réservé virgule (",") est souvent utilisé à des fins similaires. Par exemple, un producteur d'URI peut utiliser un segment tel que "nom; v = 1.1" pour indiquer une référence à la version 1.1 de "nom", tandis qu'un autre peut utiliser un segment tel que "nom, 1.1" pour l'indiquer. Les types de paramètres peuvent être définis par une sémantique spécifique au schéma,
multipart/form-data
. Pour ceux qui sont intéressés, voici une question à ce sujet .