Quand le client envoie une requête http au serveur, elle peut être de plusieurs types :

• GET
• POST
• PUT, moins utilisé
• DELETE, moins utilisé

Exemple pour GET et POST.

La requête par défaut est GET, c'est à dire obtenir. Il s'agit de lire une information du serveur : Un fichier, des données.

Un lien hypertexte <a> fait une requête GET.

Les paramètres d'une requête GET passeront dans la barre d'adresse.

Exemple :

<form action="adresse.html">
  <input type="text" name="saisie">
  <button type="submit">Envoyer</button>
</form>

Ce formulaire, contient un champ de saisie et un bouton de validation.

• On peut écrire ce que l'on veut dans le champ de saisie input. Par exemple on écrit truc.
• Le bouton de type submit, quand on l'appuie, déclenche l'envoi du formulaire.
• Comme on n'a pas précisé de méthode, ce sera GET
• Le navigateur va charger l'adresse : adresse.html?saisie=truc. Dans cette requête,
  • adresse.html était l'adresse précisée dans l'attribut action du formulaire,
  • saisie est le nom (name) du champ de saisie.

La requête POST est la deuxième requête importante.

On utilise POST quand on veut modifier l'état du serveur, quand on veut écrire sur le serveur.

Exemple : je réserve un billet de train. Ma requête va alors modifier la base de donnée de la compagnie ferroviaire. C'est une requête POST.

Si je réactualise la page, cela provoque un nouvel envoi du formulaire ce qui peut être ennuyeux (on ne veut pas réserver 2x) Je reçois donc un popup me demandant de confirmer.

<form action="adresse.html" method="POST">
  <input type="text" name="saisie">
  <button type="submit">Envoyer</button>
</form>

On retrouve le champ de saisie précédent.

• Le bouton de type submit, déclenche toujours l'envoi du formulaire, cette fois la méthode est POST.
• Le navigateur charge l'adresse : adresse.html.
• Le paramètre saisie n'apparaît pas dans la barre d'adresse (url) mais il est transmis à l'intérieur de la requête.

Remarque : dans le cas de paramètres important, comme un texte, ce peut être un avantage de ne pas les transmettre dans l'url.

En plus des requêtes POST et GET il en existe deux autres peu utilisées : PUT et DELETE.

Souvent, on n'utilise que POST et GET et alors la répartition des rôles est la suivante :

• GET pour requête de lecture,
• POST pour toute requête modifiant le serveur (ajout, modification, suppression)

Si on souhaite utiliser PUT et DELETE, on répartit ainsi les rôles :

• GET pour une requête de lecture,
• PUT pour une requête ajoutant une donnée sur le serveur
• POST pour une requête modifiant une donnée sur le serveur
• DELETE pour une requête effaçant une donnée sur le serveur

Nous avons parlé d'url qui passaient essentiellement par la barre d'adresse du navigateur et un chargement de la page. Pour dynamiser les pages web, il est devenu courant de procéder autrement.

Exemple :

Je suis sur un site marchand. Je cherche l'article chaussures.

Je l'écris sans un champ de saisie et je valide.

• la validation lance une requête vers le serveur,
• le serveur consulte sa base de données pour obtenir la liste des chaussures,
• le serveur fabrique entièrement un nouveau fichier html contenant toute la page et en particulier la liste de chaussures,
• le serveur envoie ce fichier en réponse,
• le client reçoit la réponse et l'affiche,

Comprenez bien : cet échange à conduit à réactualiser entièrement la page. Si certains éléments de la page n'ont pas changé (comme l'entête) il a néanmoins fallu les afficher de nouveau.

• la validation lance une requête qui demande seulement la liste des articles correspondant (ici les chaussures)
• le serveur consulte sa base de données pour obtenir la liste des chaussures,
• le serveur renvoie seulement la liste de chaussures,
• le client reçoit la liste de chaussures et en utilisant, côté client, le programme JavaScript (chargé au préalable) il modifie l'affichage pour y inclure la liste de chaussures.

Dans cette approche, lors du premier chargement, le client reçoit un gros fichier JavaScript qui contient tout le programme nécessaire pour gérer l'affichage. Les échanges suivants sont limités car le serveur n'envoie que les informations nécessaires. Le client qui est largement inoccupé s'occupe de calculer le nouvel affichage ce qui allège le travail du serveur.