The HTML specifications technically define the difference between "GET" and "POST" so that former means that form data is to be encoded (by a browser) into a URL while the latter means that the form data is to appear within a message body. But the specifications also give the usage recommendation that the "GET" method should be used when the form processing is "idempotent", and in those cases only. As a simplification, we might say that "GET" is basically for just getting (retrieving) data whereas "POST" may involve anything, like storing or updating data, or ordering a product, or sending E-mail.
The HTML 2.0 specification says, in section Form Submission (and the HTML 4.0 specificationrepeats this with minor stylistic changes):
If the processing of a form is idempotent (i.e. it has no lasting observable effect on the state of the world), then the form method should be
GET. Many database searches have no visible side-effects and make ideal applications of query forms.- -
If the service associated with the processing of a form has side effects (for example, modification of a database or subscription to a service), the method should be
POST.
In the HTTP specifications (specifically RFC 2616) the word idempotent is defined as follows:
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.
The word idempotent, as used in this context in the specifications, is (pseudo)mathematical jargon (see definition of "idempotent" in FOLDOC) and should not be taken too seriously or literally here. The phrase "no lasting observable effect on the state of the world" isn‘t of course very exact either, and isn‘t really the same thing. Idempotent processing, as defined above, does not exclude fundamental changes, only that processing the same data twice has the same effect as processing it once. But here, in fact, idempotent processing means that a form submission causesno changes anywhere except on the user‘s screen (or, more generally speaking, in the user agent‘s state). Thus, it is basically for retrieving data. If such a form is resubmitted, it might get different data (if the data had been changed meanwhile), but the submission would not cause any update of data or other events. The concept of changes should not be taken too pedantically; for instance, it can hardly be regarded as a change that a form submission is logged into the server‘s log file. On the other hand, sending E-mail should normally be regarded as "an effect on the state of the world".
The HTTP specifications aren‘t crystal clear on this, and section Safe Methods in the HTTP/1.1 specification describes the principles in yet another way. It opens a different perspective by saying that users "cannot be held accountable" for side effects, which presumably means any effect than mere retrieval:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
The concept and its background is explained in section Allowing input in Tim Berners-Lee‘s Style Guide for online hypertext. It refers, for more information, to User agent watch points, which emphatically says that GET should be used if and only if there are no side effects. But this line of thought, however logical, is not always practical at present, as we shall see.