Get ou Post

[stever34]

Salut, il existe deux méthode pour ebnvoyer des information dans mon petit manuel du PHP on m'explique que get envoie les info a travers l'URL alors que Post reste plus discret.

Poste est présenté comme un get mais en mieux.

Alors pourquoi ne pas toujours employer POST quels sont ses déséventages ?

[captain_torche]

Pour une raison toute simple : POST ne peut être envoyé que par le biais d'un formulaire.

On ne peut également pas non plus enregistrer dans ses favoris, les paramètres passés en POST à une page.

De manière générale, on agit comme ça :

- données envoyées en POST dans le cadre d'un formulaire.

- données envoyées en GET dans la plupart des autres cas (pseudo-frames, paramètres de pages, etc).

[Lanza]

Poste est présenté comme un get mais en mieux.

Ben non. S'ils existent tous les deux, c'est bêtement parce qu'il ne servent pas à la même chose.

POST sert à envoyer des informations.

GET sert à demander une ressource.

Dans le cadre d'un formulaire de recherche, par exemple, GET est indiqué : tu vas demander le document résultant de la requête. Comme la requête passse dans l'url, il est possible de la bookmarker.

A contrario, dans le cadre d'un formulaire de contact, POST est plus adapté. On ne demande rien, on envoie des infos et en retour on reçoit une confirmation qui n'a pas vocation (ni d'intérêt) à être bookmarké. De plus, la plupart des navigateurs intègrent une sécurité qui fait qu'on ne peut pas renvoyer deux fois les mêmes informations par POST sans confirmation.

Modifié 24 Août 2006 par Lanza

[Compte supprimé]

- données envoyées en POST dans le cadre d'un formulaire.

A contrario, dans le cadre d'un formulaire de contact, POST est plus adapté.

Faites votre choix

[objectifweb]

Bonjour,

Et quand on sait pas si on va utiliser POST ou GET on utilise REQUEST qui prend autant les get que les post...

Patrick

[v4np13]

Le POST, je l'utilise quand ce sont des données que tout le monde ne doit pas connaître tel que les mots de passe. Il est hors de question de passer ce genre de données par URL, même cryptées, il suffit qu'un petit comique passe par là et regarder les URL, on a l'air bien après...

Le GET, il passe les données dans l'URL, je m'en sers principalement pour passer d'une page à l'autre avec un bouton, il génèrera une url de ce type: www.monsite.com/?ncat=3&npage=10. Après il suffit de les récupérer et d'afficher le bon contenu.

Ce qu'il faut retenir, le POST pour la sécurité et envoi d'email, le GET pour le reste.

[captain_torche]

Et tant qu'à faire, on évite d'utiliser le $_REQUEST, qui est potentiellement moins sécurisé qu'un $_GET ou un $_POST

[manmachine]

Et tant qu'à faire, on évite d'utiliser le $_REQUEST, qui est potentiellement moins sécurisé qu'un $_GET ou un $_POST

Tiens, et en quoi $_REQUEST serait'il moins sécurisé qu'un $_GET ou un $_POST ?

[captain_torche]

Dans un script codé un peu bancalement, il serait très facile de "zapper" certaines sécurités, par exemple en passant en GET une variable qui aurait dû se trouver en COOKIE.

[Spidetra]

GET et POST sont deux méthodes du protocole REST ( Representational State Transfer ).

Comme le dit Lanza GET et POST n'ont pas le même rôle.

En pratique, on utilise GET indistinctement pour récupérer une ressource ou pour poster des données.

Le protocole REST comprend au moins 4 méthodes : GET, POST, PUT, DELETE.

Ces 4 méthodes peuvent être comparées aux CRUD d'une DataBase.

Dans le cadre d'échange de données, REST est moins populaire aujourd'hui que des protocoles comme SOAP.

C'est peut-être en train de changer avec le développement de RSS et ATOM.

Des petites sociétés comme Google, et d'autres ( SAP, Oracle, etc... ) essayent de populariser REST pour des échanges inter-serveurs en ayant des fonctionalités CRUD.

L'API de Google GDATA se base sur le protocole REST.

L'association de REST et ATOM/RSS apporte une nouvelle souplesse dans les échanges de données.