The fundamental differences between "GET" and "POST"

The HTML specifications technically define the difference between and so, former "GET" "POST" means that form Data is to being encoded (by a browser) into a URL while the latter means, the form data is to appear within a message Bo Dy. But the specifications also give the usage recommendation that the "GET" method should is used when the form proc Essing is ' idempotent ', and in those cases only. As a simplification, we might say that's "GET" basically for just getting (retrieving) data whereas "POST" Volve anything, like storing or updating data, or ordering a product, or sending e-mail.

The HTML 2.0 specification says, in sections Form submission (and the HTML 4.0 specificationrepeats this with Mino R stylistic changes):

If the processing of a form is idempotent (i.e. it had no lasting observable effect on the state of the world) and then the F Orm method should be GET . Many database searches has no visible side-effects and make ideal applications of query forms.

- -

If the service associated with the processing of a form have side effects (for example, modification of a database or SUBSC Ription to a service), the method should is POST .

In the HTTP specifications (specifically RFC 2616), the word idempotent is defined as follows:

Methods can also has 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 wordidempotent, as used in the specifications, was (pseudo) mathematical jargon (see definition of "idempotent" in Foldoc) And should not being 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 th E same thing. Idempotent processing, as defined above, does not exclude fundamental changes, only that processing the same data twice ha s the same effect as processing it once. But here, in fact, idempotent processing means that a form submission causesno changesAnywhere except on the user's screen (or, more generally speaking, in the user agent's state). Thus, it's 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 wo Uld notcauseAny update of the data or other events. The concept of changes should not being taken too pedantically; For instance, it can hardly was regarded as a change that a form submission was logged into the server ' s log file. On the other hand, sending e-mail should normally be regarded as "a effect on the" the ".

The HTTP specifications aren ' t crystal clear on this, and sections Safe Methods in the http/1.1 specification desc Ribes the principles in yet another. It opens a different perspective by saying so users "cannot be held accountable" for side effects, which presumably mean s any effect than mere retrieval:

In particular, the Convention has been established, the GET and HEAD methods should not having the significance of taking an action other T Han 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 it, so, the user is MA De aware of the fact, 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, the some dynamic resources consider that a feature. The important distinction here's the user did not request the side-effects, so therefore cannot be held accountable For them.

The concept and its background are explained in sections allowing input in Tim Berners-lee ' s Style guide Line hypertext. It refers, for more information, to the User Agent watch points, which emphatically says that GET should be used if And only if there is no side effects. But the line of thought, however logical, was not always practical at present, as we shall see.

The fundamental differences between "GET" and "POST"