Ce n’est pas particulier à REST, mais à HTTP d’un manière générale. Pour faire simple, on utilise GET pour obtenir des données, et POST pour transmettre des données, même s’il est parfaitement possible d’envoyer des données avec GET et d’en recevoir avec POST.
la balise form a des attributs method qui permettent de dire au serveur de quelles manière sont passés les informations … et action qui permet de dire au serveur quel script sera utilisé pour traiter les informations codées.
Pour la method, il existe deux valeurs possibles … get … ou … post.
get : les données sont rajoutées à l’URI par l’attribut action (avec un séparateur: ?) … donc visibles : à réserver pour des données non sensibles. Les données sont transmisent de l’ordinateur au serveur.
post : les données sont incluses dans le formulaire … donc invisibles : à réserver pour des données sensibles, les données dont on se sert sont déjà sur le serveur … elles ne sont pas transmisent …
Tiens d’ailleurs, en parlant de cet attribut method des formulaires, quelqu’un sait pourquoi la spec HTML5 n’a pas ajouté PUT et DELETE pour ne citer que ces deux verbes ?
Une balise en ligne sur le statut du contenu en HTML5 :
contenu ajouté : <ins> qui marque une portion de contenu ajouté dans le document,
contenu supprimé : <del> marque une portion de contenu amené à être supprimée du document
Ils peuvent être donc utilisés dans les formulaires, non ? si j’ai bien compris la demande …
J’évoquais :
<form method="PUT">
au lieu de devoir utiliser des hacks du style :
<form method="POST"><input type="hidden" name="_method" value="PUT">J’ai pas de réponse …
Il y a une super discussion à ce sujet sur stackexchange
At this point, it seems that the main reason why there is no support for these methods is simply that nobody has taken the time to write a comprehensive specification for it.
2 « J'aime »
J’ajouterai que si on veut être RESTFul
-
GETne doit servir qu’à récupérer des informations et en aucun cas altérer. De ce faitGETest Safe & Idempotent.GETne peut contenir debody, les paramètres sont exclusivement viaqueryString -
POSTdoit servir à créer une nouvelle ressources, si on souhaite update il existePUTouPATCH.POSTest donc Unsafe et non Idempotent cependant il peut contenir unbody(mais il n’est pas interdit de passer des paramètres enqueryString).
Voir la RFC http://ietf.org/rfc/rfc2616 section 9.1 Safe and Idempotent Methods, 9.3 GET et 9.5 POST.
C’est pour cela qu’une application RESTFul on n’applique pas de CSRF protection sur le GET.
A savoir qu’il n’y a pas de limite sur les VERB Http (il existe plein de RFC pour normalisé le plus connu comme la RFC 2616, RFC 2518, RFC 3253, …) donc ceci sont des recommendations RESTFul, libre à vous de les respecter ou non.
PS: pour plus d’info sur la notion de safe & idempotant http://restcookbook.com/HTTP%20Methods/idempotency/
4 « J'aime »
Tout a fait. Il faut bien connaitre ces règles qui sont pertinentes dans 99% des cas. Mais il y a effectivement 1% de cas ou c’est légitime de les enfreindre, par exemple le fait de ne pas pouvoir utiliser de body pour un GET peut créer des problèmes.
Un très bon article de dropbox qui explique pourquoi ils ont du remplacer certains appel GET par des POST à cause de ça :
https://blogs.dropbox.com/developers/2015/03/limitations-of-the-get-method-in-http/
Et une critique assez constructive qui propose d’autres alternatives quand on est limité par l’absence de body :
http://evertpot.com/dropbox-post-api/
3 « J'aime »