Benefits Of Get Vs. Post

[joshspaulding]

I have a super newbie question for you guys today. I'm almost done with a PHP tutorial and for the most part I understand very basic PHP. In some cases the confusion isn't in how something works or how it's accomplished that is challenging to me, but why and/or when it is used.

 

Like get and post with forms. I understand how they both work for the most part, but I don't understand why you would ever use get instead of post. They accomplish the same thing, correct? From my understanding, the only difference is that get appends the variables to the URL, whereas post hides the variables. But both options accomplish the same thing.

 

Or is my understanding wrong? If I'm right, then why would you ever need to use get?

Edited December 14, 2012 by joshspaulding

[MDCode]

Say you want to delete a profile comment from a user. Get would work better in this case because otherwise you would need a hidden field to carry the id of said comment. Users can edit hidden fields whenever they want.

Edited December 14, 2012 by SocialCloud

[joshspaulding]

Say you want to delete a profile comment from a user. Get would work better in this case because otherwise you would need a hidden field to carry the id of said comment. Users can edit hidden fields whenever they want.

 

Thanks for the reply. ok, so the benefit of get is in it's ability to bypass hidden fields. Is that THE benefit or only one of many examples?

[DavidAM]

The http specifications recommend using GET for retrieving content (i.e. the user wants to "get" a page) and using POST for actions that will change something (i.e. Insert, update, delete data).

 

The maximum allowed length of the URL is limited (by the http specification), so if you are submitting data such as this post here, using GET may result in the data being truncated (chopped-off) or the request failing entirely. (Note that the maximum size of POST data is also limited. But that limitation is a configuration setting on the server and may be modified.)

 

The URL string can be copied, bookmarked, and even emailed to other people. It might even get indexed by a search engine. If that happens, all of the data is in the url and the data update would be performed again.

 

If you have a Search Form that is a separate "page" from the results page or an alternate route to the results page; you could use GET with the form. Then the fields are in the URL where the results script expects them. Perhaps the results page also allows some search refinement, or pagination, which is handled as a hyperlink and not as a form, so it is added to the url string.

 

Say you want to delete a profile comment from a user. Get would work better in this case because otherwise you would need a hidden field to carry the id of said comment. Users can edit hidden fields whenever they want.

@SocialCloud: That really makes no sense at all. Users can modify the GET request just as easily. And it is contrary to the specification -- actions should use POST. And regardless of what method is used, the script should verify that the user has permissions to perform the action. And if the user has permission, it really does not matter that they supplied the ID by trickery.

[MDCode]

@SocialCloud: That really makes no sense at all. Users can modify the GET request just as easily. And it is contrary to the specification -- actions should use POST. And regardless of what method is used, the script should verify that the user has permissions to perform the action. And if the user has permission, it really does not matter that they supplied the ID by trickery.

 

As you said, it can be used either way. However, using GET is a much neater way in my opinion, and I was expressing it in an example. I never said that GET was better, and I never said that POST was.

[kicken]

As you said, it can be used either way. However, using GET is a much neater way in my opinion, and I was expressing it in an example. I never said that GET was better, and I never said that POST was.

 

The problem with trying to do things that change the DB with a GET request is that these things may be done by accident.  Say you had a list of users on your site with a delete link next to each one, and somehow google or another search engine found that page.  Once it crawled it and tried to crawl all those "Delete" links, oops, there goes your entire user base.  

 

There have been cases similar to that in the past.  For example Google had released a browser add-on at one point that would "make web-browsing faster" by trying to predict which links a user might click on next and then pre-load them in the background.  There were a fair number of people complaining that things kept getting deleted from there db somehow because whoever developed the system just did a a link like delete.php?id=blah with either no verification or just a JS popup which was ignored by the tool (and would be also by bots). Once the addon pre-fetched that URL it would silently delete those items.

 

That is why even though a GET may be easier/more convinent, you need to send actions that might result in a modification of the server data using a POST.  Bots and add-ons (unless programmed poorly/maliciously) will not follow anything that makes a POST request.

 

[Langstra]

The maximum allowed length of the URL is limited (by the http specification), so if you are submitting data such as this post here, using GET may result in the data being truncated (chopped-off) or the request failing entirely. (Note that the maximum size of POST data is also limited. But that limitation is a configuration setting on the server and may be modified.)

The limitations of the url are most of the times, if not all of the times, a bottleneck. For instance take the jqueryui themeroller. When you edit a style download it there is always a link provided so you can edit your style later again. That link contains the styling of the whole theme.

Look at this url, it is a jquiryui theme.

http://jqueryui.com/themeroller/?ffDefault=Helvetica%2CArial%2Csans-serif&fwDefault=normal&fsDefault=1.1em&cornerRadius=5px&bgColorHeader=888888&bgTextureHeader=04_highlight_hard.png&bgImgOpacityHeader=15&borderColorHeader=404040&fcHeader=ffffff&iconColorHeader=cccccc&bgColorContent=14141a&bgTextureContent=01_flat.png&bgImgOpacityContent=16&borderColorContent=404040&fcContent=f9f6f6&iconColorContent=bbbbbb&bgColorDefault=9e9e9e&bgTextureDefault=03_highlight_soft.png&bgImgOpacityDefault=100&borderColorDefault=cccccc&fcDefault=333333&iconColorDefault=666666&bgColorHover=adadad&bgTextureHover=05_inset_soft.png&bgImgOpacityHover=60&borderColorHover=dddddd&fcHover=000000&iconColorHover=c98000&bgColorActive=14141a&bgTextureActive=06_inset_hard.png&bgImgOpacityActive=35&borderColorActive=d4d4d4&fcActive=ffffff&iconColorActive=ffffff&bgColorHighlight=fbf9ee&bgTextureHighlight=04_highlight_hard.png&bgImgOpacityHighlight=55&borderColorHighlight=fcefa1&fcHighlight=363636&iconColorHighlight=2e83ff&bgColorError=fef1ec&bgTextureError=02_glass.png&bgImgOpacityError=95&borderColorError=cd0a0a&fcError=cd0a0a&iconColorError=cd0a0a&bgColorOverlay=aaaaaa&bgTextureOverlay=01_flat.png&bgImgOpacityOverlay=0&opacityOverlay=30&bgColorShadow=aaaaaa&bgTextureShadow=01_flat.png&bgImgOpacityShadow=0&opacityShadow=30&thicknessShadow=8px&offsetTopShadow=-8px&offsetLeftShadow=-8px&cornerRadiusShadow=8px