Pour commencer par le commencement, $_REQUEST est un tableau associatif constitué du contenu des variables $_GET, $_POST, $_COOKIE.
Nombreux sont ceux qui se disent au premier abord que cela est vraiment important de pouvoir distinguer la provenance des informations. Si l'utlisateur envoie les données par l'url (méthode "get") ou via un formulaire utilisant la méthode "post" qu'est-ce qui est le plus important ? La façon de recevoir les données ou les données elles-même ? Pour ma part je pense que la façon de recevoir les données n'a aucune importance. L'important est de bien contrôler ce que l'on reçoit et de ne faire confiance à aucune donnée même celles qui pourraient sembler anodines et non modifiables telle que $_SERVER['PHP_SELF'] [1]. Du coup l'utilisation de $_REQUEST serait plutôt déconseillée aux débutants qui ont déjà du mal à bien faire la différence entre $_GET et $_POST. Ceux-ci se contentent généralement de peu de vérifications sur les données transmises via la méthode "post"; ces données leur semblent sûres. Je ne parle même pas des cookies!
On pourrait se dire que l'utilisation de $_REQUEST pourrait être intéressante pour les cas où on laisse le choix aux utilisateurs de transmettre les données en utilisant la méthode "get" ou la méthode "post". La gestion de la provenance des données serait ainsi transparente.
Je vois un réel intéret d'utiliser $_REQUEST pour le cas où je veux continuer une session valide sans dépendre de la configuration du serveur, c'est-à-dire sans se demander de quelle manière transite l'identifiant de session (soit par cookie, soit par l'url soit par un champ caché d'un formulaire) alors au lieu d'utiliser une cascade de if pour savoir d'où vient l'identifiant je peux utiliser un code tel que:
<?php
if (isset($_REQUEST[session_name()])) {
session_start();
}
?>
Pour conclure je ne suis pas complétement convaincu d'utiliser ce tableau magique qu'est $_REQUEST surtout si on se réfère à l'utilisation des méthodes "get" et "post" et sur une architecture REST d'une application web. Les méthodes "get" et "post" sont bien distinctes et donc récupérer les données sans en connaitre la provenance leurs fait perdre un peu de leur sens.
[1] Je m'égare; ce sera l'objet d'un prochain billet. Oui j'ai honte de faire du teasing!
1 De mathiasm -
La source peut quand même avoir une importance. Dans le cas de sites dits sensibles, l'utilisation de $_REQUEST permettrait de "surcharger" une variable $_POST pour éventuellement faire de la corruption de données. Ca dépend aussi si $_GET est inséré avant ou après $_POST dans $_REQUEST.
2 De Nicolas -
La source pourrait avoir de l'importance si tu avais la même variable provenant de deux sources différentes: par exemple "get" et "cookie". L'ordre d'insertion est défini par la directive variables_order qui a pour valeur par défaut EGPCS, ce qui veut dire "ENV, GET, POST, COOKIE puis SESSION". Donc dans mon exemple si le nom de variable est le même la variable dans $_REQUEST aura la valeur du cookie. Mais quelle importance ? Il n'y a pas de corruption de données.
3 De Palleas -
Personelement j'aime pas utiliser $_REQUEST[], j'aime bien savoir exactement d'ou viennent mes données
4 De Webdeb73 -
[quote]Du coup l'utilisation de $_REQUEST serait plutôt déconseiller aux débutants[/quote]
On dit [b]déconseillée[/b] ^^
Pour en revenir au fond du billet, je suis du même avis que Romain. J'aime savoir d'où proviennent mes variables. Ainsi j'utiliserai $_SESSION, $_COOKIE, $_POST et $_GET en conséquence. L'intérêt que je vois à faire cette distinction concerne la maintenance du code. En cas de débbugage de code, je peux savoir plus facilement d'où viennent exactement mes données. Si la méthode est GET ou POST je m'orienterai plus sur la vérification de mon formulaire par exemple plutôt que sur des variables de session. Je ne suis pas très clair dans ce que je dis mais le fait de distinguer aide particulièrement à la relecture du code.
Si je mets ça par exemple :
<?php
echo "L'id de ce topic est : ", $_GET['id'];
?>
En relisant mon code plusieurs semaines à plusieurs mois après, je saurais que ma variable id est transmise dans l'url. Ainsi, en cas de débuggage de la valeur de celle ci, je saurais où orienter mes recherches. En revanche, si j'écris :
<?php
echo "L'id de ce topic est : ", $_REQUEST['id'];
?>
En cas de débuggage, par où je commence ? J'ai le choix entre GET, POST, COOKIE et SESSION. On en déduit donc une certaine perte de temps dans la recherche vu qu'il faut d'abord résoudre le problème de la provenance de la variable avant de commencer les dits tests de débbugage.
Même si j'apprécie la disparité de GET et POST, je vais entièrement contredire mes propos précédents. Je pourrais ainsi trouver un certain intérêt à REQUEST dans la mesure où j'uniformiserai le tout. Je ne me soucierai plus de la provenance de mes variables en lisant le code. Le problème de débbugage et de maintenance du code se pose alors. Comment savoir d'où viennent les données ? Pour remédier à ce soucis, il faudrait se mettre dans la peau d'un "bon" programmeur qui définit correctement toutes ses variables en tête de code et qui écrit des cartouches avec des informations claires sur la provenance des variables. De ce fait, je pourrais utiliser REQUEST si je suis concis et minutieux dans l'écriture de tout mon code. Voici comment je procèderai alors si j'utilisai REQUEST avec l'exemple précédent :
<?php
/********************************************************
VARIABLES :
- id : transmise en GET dans l'url
- login : variable de session
*********************************************************/
echo "L'id de ce topic est : ", $_REQUEST['id'];
echo '<br />',
echo 'Votre login est : ', $_REQUEST['login'];
?>
Du fait de la présence d'un cartouche en tête de code, je peux faire la différence dans la provenance des données. En lisant le code tel quel c'est impossible mais grâce à mon cartouche je peux savoir tout de suite. La maintenance sera donc plus aisée.
En conclusion, je pense qu'il n'y a pas de véritable décision à prendre entre GET, POST ou REQUEST. Le choix doit se faire en fonction de l'esprit et de la préférence du codeur. Si ce dernier a besoin exactement de savoir d'où vienne ses données, il s'orientera sur GET et POST, sinon il pourra prendre REQUEST s'il est concis dans l'écriture de ses cartouches. Ca reste ma vison des choses, je suis donc assez partagé sur l'avis ;)
Sur ce, je vais en cours lol !
@ Bientôt !
Hugo.
5 De Nicolas -
Tu m'as fait une belle réponse de normand!
p.s: merci pour la faute d'orthographe. Je l'ai corrigée.
6 De Webdeb73 -
Et oui comme dab, je suis un incompris...
7 De Palleas -
Nan t'es un nain compris ^^
Désolé c'était pour commencer sur une sale blague :)
Je corrigerais un p'tit truc, Hugo n'est pas Nordiste mais Savoyard ? Hein une seule sale vanne par messages ? oups désolé ^^
Bon aller la je suis serieux =)
Je comprend ce que dis Hugo, d'un coté $_REQUEST est problematique dans la mesure ou on ne sait pas exactement par ou commencer en cas de maintenance, autant de l'autre coté il permet d'uniformiser le code, mais la je dis ah ah!
Je ne suis pas convaincu qu'utiliser $_REQUEST plutot que les tableaux respectifs à chaques types de données change quelque chose au niveau des ressources puisque de toute façon les données sont dans les deux groupes quoi que tu fasses donc deja de ce coté la, il n'y a aucune différence.
Je ne vois pas trop l'utilité d'uniformiser le code uniquement avec des $_REQUEST plutot qu'utiliser les $_SESSION and co, je l'ai dis ca ne change rien au ressource et la j'ajoute un autre argument : c'est carrement moins clair pour moi ! (Pour moi dans le sens mon avis perso pas dans le sens vu que je suis un demeuré ^^).
Même si tu places en haut dans des commentaires
/* Variables */
nom=>vient de l'url
prenom=> vient d'un cookie
et que tu utilises $_REQUEST tu vas faire quoi si t'as 10000 lignes de codes? Il faut y revenir à chaque fois ? Bon pour 10000 lignes de code faut y aller (j'ai du atteindre les 1000 une fois mais c'était chaud et peu optimisé mais comme le dit le proverbe petit gland devient grand chène, je me suis amélioré et j'ai rarement dépassé les 200lignes maintenant ^^).
Pour conclure ce pavé qui tourne en rond, je ne suis pas convaincu du bienfondé de l'utilisation de $_REQUEST, ca me rappele le topic précedent 'ne pas réinventer la roue', il y a des tableaux propres à chaques types de données, autant les utiliser, c'est plus clair et plus pratique en cas de maintenance =)
8 De Webdeb73 -
Au final, je préfère les GET et POST pour deux raisons :
-> C'est plus pratique pour connaître la provenance des données
-> C'est plus rapide à taper que RESQUEST
Voila !
++
Hugo.
9 De Palleas -
La premiere excuse est un peu bidon :p mais je suis d'accord pour la deuxieme
en plus c'est REQUEST et pas RESQUEST :p
Faudrait faire un benckmark avec l'espacement des lettres et tout pour être sur ^^
10 De Nicolas -
Ce n'est pas un peu fini les Duponds! Ce n'est pas un chat!
11 De Palleas -
Eh mais on debattait juste :$
T'es d'accord avec nos pavés ou pas?
12 De Nicolas -
>T'es d'accord avec nos pavés ou pas?
Je ne vois pas ce qu'ils apportent de plus que le billet que j'ai écris! Pour résumé vous n'utilisez pas $_REQUEST même si vos raisons ne sont pas les meilleures. Je ne l'utilise pas non plus mais j'étudie sérieusement la question avant de faire le grand saut!
13 De Palleas -
Ben moi aussi j'étudie la question, personnelement quand je porgramme quelque chose j'ai deux buts majoritaires :
-> Pouvoir m'y retrouver facilement
-> Faire en sorte que la navigation soit agréable pour le visiteur
Pour la première raison, je prefere utiliser les tableaux $_POST $_GET et $_COOKIE, c'est une question de portabilité si je reviens sur des scripts, apres ca ne regarde que moi si je trouve ca plus pratique vu qu'il n'y a pas de différence.
Apres tu dis "pour les cas où on laisse le choix aux utilisateurs de transmettre les données en utilisant la méthode "get" ou la méthode "post"", mais la j'avoue que je suis un petit peu intrigué, je ne vois pas pourquoi on laisserait le choix à l'utilisateur, c'esst bien de lui accorder le droit de choisir mais à ce point la... Enfin ca je ne comprend pas à quoi servirait de lui laisser ce choix :s Ca t'es deja arrivé ? ^o)
Cela étant avec l'extention "WEBDEVELLOPER" de firefox, tu peux changer la methode de post des formulaires, la c'est sur que ca peux empecher le script de tourner convenablement si mon script qui utilise POST reçoit des données en GET, la c'est sur que REQUEST serait la solution :s
Si tu fais ca par exemple :
<?php
echo '<h4>Tableau recu par $_POST :</h4>';
echo '<pre>';
var_dump($_POST);
echo '</pre>';
echo '<h4>Tableau recu par $_GET :</h4>';
echo '<pre>';
var_dump($_GET);
echo '</pre>';
echo '<h4>Tableaux recu lu avec $_REQUEST :</h4>';
echo '<pre>';
var_dump($_REQUEST);
echo '</pre>';
?>
<form action="<?php echo $PHP_SELF;?>?var1=toto&var2=tutu&var3=titi" method="post">
<p><input type="hidden" name="var1" value="toto" /></p>
<p><input type="hidden" name="var2" value="tutu" /></p>
<p><input type="hidden" name="var3" value="titi" /></p>
<input type="submit" value="envoyer" name="submit" />
</form>
Ca te retourne ca :
Tableau recu par $_POST :
array(4) {
["var1"]=>
string(4) "toto"
["var2"]=>
string(4) "tutu"
["var3"]=>
string(4) "titi"
["submit"]=>
string(7) "envoyer"
}
Tableau recu par $_GET :
array(3) {
["var1"]=>
string(4) "toto"
["var2"]=>
string(4) "tutu"
["var3"]=>
string(4) "titi"
}
Tableaux recu lu avec $_REQUEST :
array(5) {
["var1"]=>
string(4) "toto"
["var2"]=>
string(4) "tutu"
["var3"]=>
string(4) "titi"
["submit"]=>
string(7) "envoyer"
["PHPSESSID"]=>
string(32) "70488e11c1ed97ff274f3dcea4da1d0d"
}
Donc il fait bien se rappeler l'ordre de priorité des variables contenu dans le tableau $_REQUEST, ou alors ne pas donner le même nom aux variables.
Je ne vois pas vraiment d'avantages à utiliser REQUEST, a par celui qui j'ai cité en haut et encore...
J'y ai quand même refléchis serieusement la non ?