Pretty much anyone who’s been on the web has undoubtedly used an HTML form at some point. Whenever you enter in any personal information on a site and hit a submit button, you are putting that information into an HTML form. A form is used to pass information from a web browser to a web server. For example, if logging into an email provider like yahoo mail or gmail, you would input your username and password inside an html form. Then, by clicking the "sign in" button you’re submitting your username and password (inside a form) from your web browser to one of Yahoo’s or Google’s webservers. There are two different ways that a form can be submitted from your browser to the webserver. In HTML, this is how one would define the opening form tags for both submission methods: <form method="GET"> and <form method="POST">. When a form is submitted, an HTTP request that passes the data to the web server is generated. Think of HTTP as the language that your web browser uses to ‘speak’ with web servers. The type of HTTP request generated depends on the method used to submit the form (either a GET or a POST).
If a "GET" request is used, the form parameters are encoded in the URL in what is called a query string. The form parameters can be anything, and in the example we gave earlier they would be the username and password for your email provider. Here’s an example of the query string that would be generated if we were to use a "GET" request: www.someemailprovider.com/?login=joe@email.com&password=xxyz |
In the GET request above, you can see that the form parameters (login and password) are attached to the end of the URL itself. Note that defining a login form to use the GET request method – as we did in this example – is a very bad idea. This is because people logging in will see their passwords being displayed in the url and may be led to think that your site is not secure. One should almost always use a POST form whenever passwords are involved, for other reasons that are explained below. A POST request, unlike a GET request, passes the form parameters in the body of the HTTP request, not in the URL. This happens behind the scenes, in what can be thought of as an HTTP ‘dialogue’ between your web browser and a webserver. However, the main difference between GET and POST requests is that GET requests are meant to be (although not always are, because this depends on the programmer of the form) idempotent. What idempotent means is that one GET request for a particular URL, including the form parameters, is the same as 2 or more requests for that URL. This is because the response page is always the same. So, your web browser can usually cache the response pages for GET requests, because they should not change. POST requests, however, are not meant to be idempotent. This means that they cannot be cached, and the server is recontacted each time the page is displayed. POST requests are most suitable for queries where the response page will change over time – like a shopping cart. With all that said, idempotence is mostly ignored in the real world. Keep in mind that no one is enforcing idempotence – its more like a best practice guide. The main thing to keep in mind as a programmer is that defining your form to use the GET method does not protect against causing changes. You could use a GET request to do pretty much the same thing as a POST query. It’s just that browsers are generally coded to expect that POST requests will be used for things that will cause changes – like placing an order, or writing to a database, etc . GET requests should be used for pure queries that don’t affect anything on the server. So, one should always remember not to use GET requests for any action that would cause a change on the server – like ordering a big screen tv. |