La méthode GET d’un formulaire HTML ou d’un envoi en Ajax n’est pas juste une manière de passer des paramètres dans l’URL. GET est une « méthode » (au sens d’une « fonction » d’un langage de programmation) du protocole HTTP. Par exemple l’URL www.monsite.com/ma-page?lang=fr peut être utilisée par une requête HTTP de type GET ou POST. S’il y a un paramètre, alors en GET il sera ajouté dans l’URL ce qui donnera : www.monsite.com/ma-page?lang=fr&mon-param=ma-valeur. En POST l’URL est utilisée telle qu’elle est et les paramètres sont envoyés à côté.
Le protocole HTTP
La RFC 2616 du W3C définit les méthodes du protocole HTTP, dont notamment les quatre suivantes pleinement exploitées en architecture REST : GET (lecture), POST (tout type d’écriture), PUT (écriture à un endroit donné à la manière d’une valeur dans un tableau associatif) et DELETE (suppression). La syntaxe des formulaires HTML n’autorise que GET et POST et dans cet article nous nous en contenterons également. Toutefois, notons que les quatre méthodes restent utilisables en Ajax (JavaScript) sur les navigateurs modernes.
GET est « safe », c’est-à-dire qu’une requête HTTP GET n’a pas de conséquence significative autre que le chargement d’une ressource. GET est en outre « idempotent » ce qui signifie que plusieurs requêtes HTTP GET identiques lancées à la suite provoquent le même effet (retournent le même contenu Web) qu’une seule. Le navigateur peut donc mettre en cache la réponse à une requête GET. GET est idéale pour les accès en lecture. Et c’est en GET que le navigateur accède au serveur lorsqu’on saisie une URL dans la barre d’adresse.
POST est au contraire non « idempotent » et non « safe » ce qui en fait la méthode la plus généraliste du protocole HTTP. On peut alors en faire ce qu’on veut sans contrevenir à la norme. On l’utilisera pour tous les accès en écriture : les ajouts, modifications et suppressions. Le résultat d’une requête POST n’est pas mis en cache par le navigateur (inutile puisqu’elle n’est pas « idempotent »).
Coté navigateur, bien choisir entre GET et POST
Pour les accès en écriture, la méthode POST doit être utilisée. C’est obligatoire. Celui qui modifie le contenu de son site Web à coups de requêtes GET est en dehors de la norme HTTP et cela a des conséquences. Si par exemple on voulait faire deux ajouts identiques en GET, le navigateur pourrait décider de mettre en cache la réponse et la resservir plutôt que de lancer deux fois l’ajout : absurde.
Pour les accès en lecture, GET doit être préféré.
Coté serveur, bien gérer POST
En PHP, si une ressource Web existe, le langage la rend par défaut accessible à la fois en HTTP GET et en HTTP POST. Ainsi, en réponse à une requête HTTP GET ou POST sans paramètres, une page PHP fournira le même document. Nous devons comprendre que c’est un choix de PHP et non pas une manière générale de faire. Par exemple en Java on reçoit les requêtes HTTP GET et POST dans deux méthodes différentes et on choisit explicitement de faire ou non le même traitement.
Le double accès par défaut des ressources PHP ne pose pas de problème particulier. La plupart des accès se feront de toute manière en GET pour la lecture des pages du site.
En écriture cependant, suite à la réception en POST des données saisies dans un formulaire HTML, un programme PHP ne devrait pas renvoyer un document Web. En effet, ce dernier ne serait pas mis en cache, ce qui pose un problème de performance, et puis le navigateur risquerait de relancer la requête POST si l’utilisateur jouait des boutons « Précédent » et « Suivant ». La RFC du W3C recommande de retourner un statut de réponse HTTP 200 (OK), 204 (Pas de contenu), 201 (Créé) ou 303 (Voir aussi). Les premiers statuts de réponse seront exploitables en Ajax. Le dernier redirigera le navigateur vers une URL à charger en GET.
Dans le cas où l’envoi en POST d’un formulaire HTML créerait ou une nouvelle page Web (cas d’un nouvel article dans un blog) ou modifierait une page existante (cas de l’ajout d’un commentaire sous l’article), le programme PHP ne devrait pas afficher la page directement. Il devrait renvoyer le code 303 accompagné de l’URL de la page à (re)charger.
En PHP, à la suite du traitement réussi des données envoyées, on écrira ceci :
header("Location: the/url/to/load", true, 303);
exit;