Qu'est-ce que le corps de la requête HTTP ?

Bonjour à vous tous,

Je viens enfin de comprendre la différence entre les méthodes GET et POST, utilisées dans la balise <form> en HTML. Avec une base de données, on a 2 options : soit on consulte son contenu, soit on écrit dans la base de données. C'est le rôle de ces deux méthodes : GET permet de consulter le contenu, c'est-à-dire d'afficher une partie de son contenu, et POST permet de changer le contenu de la base de données, c'est-à-dire ajouter, modifier, supprimer. En somme, GET "lit" et POST "modifie".

Voici un exemple de formulaire utilisant la méthode POST :


Et voici un exemple de formulaire utilisant la méthode GET :


Par contre, ce que je n'arrive pas à visualiser dans ma tête c'est que, quelque soit la méthode choisie, l'envoi des données doit se faire vers un fichier spécifié dans l'attribut action="traitement.php" (bien qu'il ne soit pas obligatoire d'indiquer cet attribut avec la méthode GET, juste recommandé). Cet envoi se fait dans le corps de la requête HTTP. C'est ça que je ne parviens pas à m'imager, qu'est-ce que le corps de la requête HTTP ? Y a-t-il moyen de visualiser ce corps quelque part ?

Merci pour vos aides et
Que le code soit avec vous !
Modifié par ObiJuanKenobi (15 May 2025 - 07:51)

Bonjour,

Tout d'abord, ce n'est pas tout à fait exact, la différence entre GET et POST, c'est que les données lors d'un envoi en GET sont encodées dans l'url alors que les données en POST sont envoyées dans la requête http, tu peux aussi passer des données binaires en POST (pour de l'upload de fichiers par exemple) alors qu'en GET, tu ne passes que des caractères ASCII.

Tu n'as pas besoin d'un formulaire pour faire du GET (contrairement au POST), d'ailleurs si tu affiches l'inspecteur réseau de ton navigateur et que tu actualises la page d'accueil du site, tu verras que l'appel se fait en GET.

Il n'y a pas d'obligation de faire de l'écriture en base lors d'un POST, par exemple un formulaire de contact peut simplement envoyer un mail depuis un site qui n'a même pas de base de données.

L'utilisation du GET pour la lecture et du POST pour l'écriture, c'est plutôt une bonne pratique qui est maintenant utilisée dans toutes les api REST (on fait du GET pour lire, du POST pour écrire).

L'envoi se fait toujours vers une URL précise pour pouvoir traiter les données, dans un formulaire, si tu ne le précise pas les données sont envoyées sur la page qui soumet le formulaire.

Tu peux visualiser le corps (le contenu) des requêtes http dans ton navigateur en affichant les outils de développement web (CTRL + MAJ + I sous Firefox et chrome) dans l'onglet 'réseau'.
Tu pourras sélectionner les requêtes et voir les entêtes et le contenu des requêtes.

Gillesr
Modifié par gillesr (15 May 2025 - 10:18)

Bonjour,

ObiJuanKenobi a écrit :
En somme, GET "lit" et POST "modifie".

Pas du tout. Les deux permettent de faire la même chose côté serveur.

La différence principale entre les deux c'est que les informations transmises via GET sont ajoutées à l'URL (elles sont donc visibles par l'internaute, sont stockées en clair dans l'historique du navigateur, etc.) tandis que celles transmises via POST ne le sont pas (elles sont donc transmises de manière plus confidentielle). Par ailleurs les informations transmises par GET sont limitées en taille, alors que celles transmises par POST ne le sont pas.

Amicalement,

Bonjour,

gillesr a écrit :
... tu peux aussi passer des données binaires en POST (pour de l'upload de fichiers par exemple) alors qu'en GET, tu ne passes que des caractères ASCII.

Certes mais on peut %-encoder les caractères non ASCII et les transmettre via GET.

gillesr a écrit :
Tu n'as pas besoin d'un formulaire pour faire du GET (contrairement au POST)

Si on utilise par exemple fetch en javascript, il me semble qu'on peut "faire du POST" sans avoir besoin d'un formulaire !

gillesr a écrit :
L'utilisation du GET pour la lecture et du POST pour l'écriture, c'est plutôt une bonne pratique qui est maintenant utilisée dans toutes les api REST (on fait du GET pour lire, du POST pour écrire).

Certes. Mais c'est purement conventionnel.
EDIT: et par ailleurs, le GET et le POST ont été "inventés" bien avant les API REST, et ont une utilisation plus large.

Amicalement,
Modifié par parsimonhi (15 May 2025 - 10:41)

Hello,

parsimonhi a écrit :

Si on utilise par exemple fetch en javascript, il me semble qu'on peut "faire du POST" sans avoir besoin d'un formulaire !

Oui, mais c'est une hérésie finalement puisqu'on va implémenter un input sans la balise <form> la plupart du temps (la sémantique et l'accessibilité en prennent un coup).

parsimonhi a écrit :

et par ailleurs, le GET et le POST ont été "inventés" bien avant les API REST, et ont une utilisation plus large.

Exact. Je me demande pourquoi les navigateurs ne prennent toujours pas en charge PUT/PATCH/DELETE

@ObiJuanKenobi
Méthodes de requête HTTP
RestFull
Modifié par niuxe (15 May 2025 - 18:48)

Bonjour,

niuxe a écrit :
Oui, mais c'est une hérésie finalement puisqu'on va implémenter un input sans la balise <form> la plupart du temps (la sémantique et l'accessibilité en prennent un coup).

J'avoue ne pas avoir bien compris ta remarque.

On n'est pas du tout obligé d'avoir une balise input pour faire du fetch derrière me semble-t-il. Ça dépend complètement de la situation, elle n'est pas forcément hérétique et elle n'est pas rare (selon moi).

Je travaille justement en ce moment sur un code js où il faut que j'aille chercher des données sur le serveur via un fetch selon une réponse "oui/non" de l'utilisateur qui lui est demandé via un dialogue (en utilisant un élément <dialog>). Pour mon fetch, j'ai éventuellement besoin de préciser des paramètres (ce que je fais via "POST"), mais ces paramètres ne proviennent pas du tout d'éléments de formulaire que l'utilisateur aurait eu à renseigner. Ils proviennent en l'occurence du localStorage dans le cas que j'ai à traiter, mais c'est du détail. Ils auraient pu provenir de n'importe où. Je ne vois pas où la sémantique ou l'accessibilité pourraient en pâtir ici.

Et c'est justement parce qu'on n'est pas obligé d'avoir des éléments de formulaire dans la page pour faire du fetch() avec la méthode POST que je citais ce cas.

Amicalement,

parsimonhi a écrit :

On n'est pas du tout obligé d'avoir une balise input pour faire du fetch derrière me semble-t-il. Ça dépend complètement de la situation, elle n'est pas forcément hérétique et elle n'est pas rare (selon moi).

Je travaille justement en ce moment sur un code js où il faut que j'aille chercher des données sur le serveur via un fetch selon une réponse "oui/non" de l'utilisateur qui lui est demandé via un dialogue (en utilisant un élément &lt;dialog&gt;). Pour mon fetch, j'ai éventuellement besoin de préciser des paramètres (ce que je fais via "POST"), mais ces paramètres ne proviennent pas du tout d'éléments de formulaire que l'utilisateur aurait eu à renseigner. Ils proviennent en l'occurence du localStorage dans le cas que j'ai à traiter, mais c'est du détail. Ils auraient pu provenir de n'importe où. Je ne vois pas où la sémantique ou l'accessibilité pourraient en pâtir ici.

Et c'est justement parce qu'on n'est pas obligé d'avoir des éléments de formulaire dans la page pour faire du fetch() avec la méthode POST que je citais ce cas.

Amicalement,

Je pense que sur ce point, tu es d'accord avec moi : Dans le développement Web, les requêtes HTTP POST sont là pour créer de nouvelles ressources, telles que l'ajout d'un fichier à un répertoire ou d'une nouvelle ligne à une table de base de données.

J'ai un peu de mal à comprendre ton contexte avec le <dialog> que tu utilises.

Je vais reprendre ton exemple de <dialog> avec un choix oui et non (dans le cas où on propose à l'utilisateur d'accepter de recevoir la newletter par exemple). Je t'invite à lire ce que j'ai écrit dans ce codepen

Sans le JS¹, ça fonctionnera ! Je veux dire dans le cas où le formulaire n'est même plus dans <dialog> et doit être déplacé dans un bloc à part (exemple : <aside>). Ah mais, le designer ou l'ux ne souhaite pas de bouton radio. Ce n'est pas un problème, les <label> auront le design d'un <button> et les <radio> en position fixed avec un left -500000px.

On demande à l'utilisateur un choix qui aura pour conséquence d'insérer une donnée en base de données (suivant le contexte dont je parle). Historiquement, c'est le formulaire. bien sûr, on peut très bien faire ceci. Maintenant, on enlève le JS¹, rien ne fonctionne.

edit :

a écrit :

Ils proviennent en l'occurrence du localStorage dans le cas que j'ai à traiter, mais c'est du détail.

Je crois comprendre ton contexte. L'utilisateur peut sauvegarder les données qu'il a en local sur le serveur ? Si c'est le cas, c'est pour moi un <form>. En outre, j'avoue que suivant le contexte, on peut très bien se passer d'un <form>. Ce contexte n'est pas commun. D'ailleurs, dans l'action du controller, si la réponse est non, je ne fais rien. En JS, je bloque le non afin qu'il n'y ait pas un appel au serveur pour rien.

Je pense souvent à développer sans le JS. Pourtant, j'en fais des masses. Je pense fréquemment au bouton imprimer. Pourquoi placer le bouton en dur si, le JS n'est pas disponible¹.
En général :
- GET et DELETE n'ont pas vraiment besoin d'un form.
- POST, PUT, PATCH le form est habituellement là.
_____
¹ par exemple : error en console, amazon, JS non intrusif/obstructif, etc.
Modifié par niuxe (16 May 2025 - 01:07)

Bonjour,

niuxe a écrit :
J'ai un peu de mal à comprendre ton contexte avec le <dialog> que tu utilises.

Imagine que je n'ai pas de formulaire du tout ni de dialogue. À un moment, une fois que la page est déjà affichée (et sans devoir la réafficher depuis le début), je dois aller récupérer des données sur le serveur et je le fais donc via un fetch (pour éviter justement le réaffichage complet). Ce fetch a besoin de paramètres servant à préciser la demande (il s'agit de récupérer des images selon certains critères qui dépendent du contexte de la demande). Y a zéro éléments html concernés lors de la demande. La page pourrait être initialement complètement vide, ça marcherait pareil.

Amicalement,
Modifié par parsimonhi (16 May 2025 - 01:46)

parsimonhi a écrit :
Bonjour,


Imagine que je n'ai pas de formulaire du tout ni de dialogue. À un moment, une fois que la page est déjà affichée (et sans devoir la réafficher depuis le début), je dois aller récupérer des données sur le serveur et je le fais donc via un fetch (pour éviter justement le réaffichage complet). Ce fetch a besoin de paramètres servant à préciser la demande (il s'agit de récupérer des images selon certains critères qui dépendent du contexte de la demande). Y a zéro éléments html concernés lors de la demande. La page pourrait être initialement complètement vide, ça marcherait pareil.

Amicalement,

Dans ce cas-là, c'est un GET puisque tu vas chercher des données venant du serveur.

Là où je parle de l'hérésie, c'est dans le contexte que le développeur utilise un ou plusieurs <input> sans qu'il y ait un <form> en amont. Un exemple ?
todomvc

<header class="header" data-testid="header">
  <h1>todos</h1>
  <div class="input-container">
    <input class="new-todo" id="todo-input" type="text" data-testid="text-input" placeholder="What needs to be done?" value="">
    <label class="visually-hidden" for="todo-input">New Todo Input</label>
  </div>
</header>

C'est d'un ridicule ! Il est obligé de gérer la touche <enter> pour ajouter une tâche. Or, <enter> soumet un <form> par défaut.

@ObiJuanKenobi: Bien que je t'aie partagé des liens à propos des requêtes HTTP, je te partage cette image (comme tu as été sage et que tu as gagné des bons points). Ça devrait t'aider à comprendre.

Bonjour,

niuxe a écrit :
Dans ce cas-là, c'est un GET puisque tu vas chercher des données venant du serveur.

Certes, mais c'est purement conventionnel. Techniquement ils peuvent tous les deux (le GET et le POST) envoyés des données au serveur ou en récupérer.

La différence technique, c'est que GET a pas mal de limitations par rapport à POST.

Mais bon, admettons qu'il faille se contraindre à bricoler un GET avec fetch quand on se contente de récupérer des données sur le serveur pour une question de sémantique, et que mon exemple était mal choisi.

Ceci étant, ça ne retire rien au fait qu'on peut utiliser la méthode POST avec fetch sans présence de formulaire, ce qui était le sens de ma remarque initiale. Et les exemples d'utilisations sont nombreux.

Amicalement,

parsimonhi a écrit :

Certes, mais c'est purement conventionnel. Techniquement ils peuvent tous les deux (le GET et le POST) envoyés des données au serveur ou en récupérer.
...
Mais bon, admettons qu'il faille se contraindre à bricoler un GET avec fetch quand on se contente de récupérer des données sur le serveur pour une question de sémantique, et que mon exemple était mal choisi.

En effet, c'est une convention (RESTfull). Je dirai une recommandation. Aussi, ça permet de préparer sans trop d'effort une évolution potentielle.
Dans les multiples app que j'ai développées, j'ai rencontré pas mal d'absurdités. Je me souviens d'une app dans laquelle, les pages textuelles avaient un <form method=post> en tant que parent. Ah les joies de .NET... Sur cette app, je n'avais fait que de l'intégration et du JS basique.

parsimonhi a écrit :

La différence technique, c'est que GET a pas mal de limitations par rapport à POST.

Je dirai des limitations et des contraintes (urlencode par exemple). Il me semble qu'à une époque, GET ne pouvait récupérer que 255 caractères maximum.
Modifié par niuxe (16 May 2025 - 15:46)