Sponsor: The CSS Anthology
The CSS Anthology: 101 Essential Tips, Tricks & Hacks (external link)
Blog Entry
POST vs. GET
Published on the 3rd of September 2008
When I first started learning web development, I had a hard time understanding the differences between the two HTTP request methods POST and GET. Some of the early Lowter members will remember an issue with only being able to post forum posts under 2000 characters, which was a result of me accidently using GET to submit the user's posts. Matt actually spotted the issue and probably wanted to reach through the computer screen and slap me for such a naïve error. Alas, I've come quite a ways since then.
Now, there is a lot of technical stuff that differentiates POST and GET (like how they are sent and such), but here I am just going to focus on the practical differences in relation to submitting HTML forms. Both POST and GET are HTTP request methods that send information to the server and that are very common in web development. Let's look at some of the key differences between POST and GET:
POST
- Form data sent inside the message body
- Virtually no restriction on length
- Not usually cached by any server or by any web browser
GET
- Form data encoded into the URL
- Maximum URL length of around 2000 characters
- Usually cached by web browsers
With GET, the data is encoded into the URL, such as page.php?order=username. This can be useful or this can present some issues depending on the situation. For example, it would be a problem to have the user's login username and password in the URL (login.php?username=ethan&password=manitoba). His neighbour could just peep over his shoulder and see his login details, which, in the face of more serious security threats, would be a pretty funny security issue. However, it is useful to have the search term in the URL, so the user can bookmark the search results page to return to later (search?q=php). Submitting data via the GET request method is best for search forms, table ordering, or anything else that might need to be bookmarked.
POST data is invisible from the user and much more secure. Granted, it wouldn't be too hard to setup a computer in front of a server to capture POST data, but unless you're working with secure data (such as credit card numbers) I wouldn't worry about it. If you are, then you'll want to look into SSL (external link). Submitting data via the POST request method is best for long texts (such as forum posts), login details, contact information, etc.
Other than for search forms, I would say that POST is usually the best option for sending data via forms. Since most form data is lengthy and often times private, POST is usually the appropriate request method. Also keep in mind that in (X)HTML, if you forget to specify the method attribute on a <form> tag, then it defaults to GET. Hopefully this blog post clears up any confusion between GET and POST requests in relation to HTML forms. Now, POST and GET can go much further in terms of the technical nature of their differences, but I hope the practical differences here are helpful.
Comments
-
Eugene Wee (3 Sep 2008 20:37)
I think that the interception of HTTP requests are not just theoretical events but a real security risk, hence the use of SSL/TLS and such for e-commerce.
It would also be interesting to point out the concept of idempotence. Sure, it is a technical term, but it does have practical consequences :)
"The "get" method should be used when the form is idempotent (i.e., causes no side-effects). Many database searches have no visible side-effects and make ideal applications for the "get" method.
If the service associated with the processing of a form causes side effects (for example, if the form modifies a database or subscription to a service), the "post" method should be used."
The above is as stated in the W3C Recommendation for HTML 4.01:
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.1 -
Ethan Poole (external link) (3 Sep 2008 20:57)
I think my subconscious notion to use a "fancy" word jumped ahead of reality, lol. Fixed though, although I still think in most cases you won't have to worry about it unless you're processing credit card information or socials. However, describing GET and POST using the W3C's words is generally confusing and sounds pompous. I just wanted to give practical applications for each request method, rather than some generalised statement.
Sponsor: Songbird Media Player
Desktop web player, a digital jukebox, and web browser mash-up. (external link)
