Introduction

The action of a Web form may either specify POST or GET as the method of operation.  The difference is in how the parameters specified in the form are passed to the Web application;  POST sends them as a binary attachment to the HTTP message, GET incorporates them into the URL as a querystring.   For example, the following URL GET's, from an application called map.adp, a map of the zipcode in which the Hayes Rd office lives: http://www.mapquest.com/maps/map.adp?zipcode=77082.

This note will explore the issue of whether one should use GET or POST.  An attempt will be made to follow the guidelines on this subject from the Technical Architecture Group (TAG) of the World Wide Web Consortium (W3C), but the treatment will be less technical and accurate.  On the other hand, however, I will not use words like "idempotent", which may be part of your everyday vocabulary but is not really in mine.  I will also make some effort to conform to common usage and best practices both in ChevronTexaco and the W3C, as best I understand them.

This exposition, although generally informal, will attempt to use the words must, should and may in the formal sense.  That is, must means that there is no choice, do it this way please.  Should means that you can do it another way if you have a reason,  but it is generally best practice to do it this way.  May means that you are allowed but not particularly encouraged to do it.  (There are actually more formal definitions of these terms, but this should suffice).

You will probably notice that all the musts will refer to POST.  The strongest statements about using GET will say should.  So, I guess if you never want to think about it you could use POST all the time, but that wouldn't really be the best thing to do.  As you will see, there are circumstances where GET has some real advantages.

One final note in introduction:  This is an issue that some people really care about, both in ChevronTexaco and the wider Web community, and sometimes it is not exactly clear to me why passions run so high.  This note will attempt to take a fairly laid back approach that may not be very congenial to the people with high energy on the subject.  My objective is to give you some guidelines that are sensible, not to lay the issue to rest for all purposes.

Top

Use GET to Read Data

-Discussion

There are also some potential advantages to GET on the network level because the information is easily available to functions on the network servers.  This could be used to enable caching, filtering or routing.  In practical terms, however, our network people have not been very big on exploiting these opportunities, for reasons that are beyond the scope of this note, so I don't consider this a very strong motivator for using GET.

-Exceptions

You must use POST if the total length of the URL for a GET, taking into account the longest possible length for all parameters, might exceed 2080 characters.  I cannot find documentation of this limit for IE 6, but we have tested it.  Don't try to get close to this limit - special characters in the parameters can turn into escapes that use more characters. If you exceed it the form won't work.

You  must use POST if the parameters contain sensitive information.  Of course what it sensitive is a judgment call, but UserID/Password's are generally sensitive, so establishing the security context for a Web application should generally be done using POST.  The problem here is that the information in GET's are more visible than in POST's.  The URL that includes the parameters may be displayed on a browser screen or kept in cache in various locations where it may be viewed accidentally.  Do not, however, delude yourself that information sent via POST is safe against a determined attack;  use HTTPS if this is a real concern.

Top

Use POST to Write Data

-Discussion

Except as detailed below, you must use POST to write data or for operations that significantly change the state of the Web or data server.  The reason for this is exactly the flip side of the GET-advantage coin -- in general you don't want to bookmark a data writing operation because you want to be careful about the context in which you do it.

-Exceptions

You may use GET for data writing operations that are really safe to do at any time in any context.  In other words, it either will do nothing (perhaps including situations where it is invoked without first setting up the security context) or do no harm.  One hint that an operation might fit this description is if performing the operation multiple times has the same effect as doing it once.  (This is what "idempotent" means, at least to some people).  I find it kind of hard to think of situations that fit this description, but maybe some cleanup operations would work.  I suggest that you think carefully before you do this, both about whether the operation is really safe and whether a user would find it useful to bookmark it.

Top

Conclusions

GET and POST are both useful techniques.  You should use each where appropriate.  If in doubt use POST, but don't take this to an extreme -- some cases are going to be judgment calls.