Public Class GeoffAppleby : What's the difference between a GET and a POST request? And HEAD?

Navigation

Archives

What's the difference between a GET and a POST request? And HEAD?

A week or two ago I wrote a little rant about how we're having trouble finding a suitable contractor to do some work for us. During the rant, I mentioned one of the questions I asked to get a feel for how much knowledge the interviewees had.

What's the difference between a GET and POST request?

Over the last week, Google has started sending people to that post who looking for an answer to that specific question. Since people want to know, and seem to expect me to tell them, I figured I'd better answer it *grin* For the full description of it all, have a read of the HTTP/1.1 RFC (2616), which describes the specification. For older stuff, the HTTP/1.0 RFC (1945) is still worth reading too.

When a request is made to a web server, a message in a known format is sent. It consists of two parts - request headers, and a request body. Some headers are mandatory, and others are optional. A request body is only included if required - GET does not have one and must not have one. Headers are split by a new line (CRLF), and the header section is marked complete with a double newline.

There are only two request headers that are absolutely essential - the Request-Line, and a Host header (in HTTP/1.1, it's not defined in the HTTP/1.0 specification). The Host header names the server you attempting to contact so that server hosting multiple sites can resolve which instance you require.

The Request-Line is the crux of everything. It consists of the format 'Request-Method Request-URI HTTP-Version'. Some example request lines are (the double dash is a comment, only pay attention to the bold :):

GET /blogs/geoff.appleby/default.aspx HTTP/1.1 --to get my main page
POST /blogs/geoff.appleby/someentry.aspx HTTP/1.1 --to submit a comment on a post, say.

In both cases we could include some query string parameters:

GET /blogs/geoff.appleby/default.aspx?foo=bar&fnord=cow HTTP/1.1

The querystring is supposed to be used to locate a specific resource, or dynamically locate a piece of data, that sort of thing. It's supposed be used for discovery and identification. Again, it can be used for both GET and POST.

So what's the difference? GET is supposed to be used to only retrieve a resource (static or dynamic). POST is supposed to be used to send data TO a resource.

So where does this data get sent? In a POST, as well as request headers you include a message body. Just like how the querystring is a set of name/value pairs (separated by &'s), the message body for a POST request is a just a set of name/value pairs, separated by newlines (CRLFs).

And this, essentially, is the only difference. It's the way in which name/value pairs are sent up to the server. There's a lot more involved in what you can do with either of them (for example, only on certain conditions - depending on different optional headers - can the response to POST request be cached, but these are more usage rule differences rather than actual differences in what's sent), but generally it's safe to say that this is all it is. There's also a size constraint in place here. Any request Uri (including the querystring) can normally only be at most 1024 characters long (give or take a char or two - not sure about null terminators :) but the request body can be much larger (chosen by each individual web server, not the specification) so you can upload a lot more data via POST.

Notice how I italicised the word 'supposed' several times above? The intent of these request methods is as I've stated. You can actually get around this however. In HTML you, can certainly do <FORM method="get">, and have the form params submitted only via the querystring, and update data as a result. It just depends on how each page has been implemented.

And what's a HEAD request? It's exactly the same as a GET request, but the web server must not return the requested resource. A response, just like a request, consists of headers and a body - the headers describe meta information about the resource requested (it's size, it's mime type, if it couldn't be located, etc) and the body is the actual resource content. So the result of a GET request is some headers and a body. The result of a HEAD request is the exact same headers as if it was a GET request, but NO body. Easy huh?

There's also a few more request method types available for use, but I won't go into the here - read the RFC's to find out about them, or to find out more about what I've talked about. It is interesting though that with GET and POST being the two most common request methods out there, a web server only optionally has to implement a handler for POST requests. Only GET and HEAD are mandatory for implementation. Funny.

Side note: When asked in the interviews I mentioned at the start, I was certainly not expecting an answer as detailed as this. A simple sentence or two like 'POST is for submitting data, GET is for getting data' or 'POST data is sent after all the header' would have been more than enough to keep me happy :)

Listening to: enough space - foo fighters - (2:37)

Posted: Wednesday, 17 August 2005 11:42 PM by Geoff Appleby

Filed under: General, Tricks

Comments

Darrell said:

Let me guess: you've been doing web programming since the mid-90's? Me too, and back then we HAD to know these things because most of us were working directly with the API. Remember CGI? That sucked! Life was so much better once I found the cgi-perl what they now call modules, but this was way before CPAN.

APIs move us up levels of abstraction. Some people that do "web programming" with ASP.NET don't know that you can't just checked for a checkbox's value from the Request if the box was not checked. You have to see if the checkbox exists in the request, and if so get the value, else set a default value. They think you just check myCheckBox.IsChecked! Yes we know it saves us 5 lines of VBScript, but they don't know what you used to have to do to work with checkboxes, and that it wasn't that easy.

So moving up levels of abstraction is great, except when the abstractions are leaky like that old Spolsky essay everyone has read. But where do we draw the line? I think your question was definitely in bounds, but should you ask that question 5 years from now? Maybe, maybe not. 5 years from now you'll be a web guru or something because you know what get and post do, and everyone will think that doing plain ASP.NET work is like going to unmanaged C++ is to us! :)

# August 18, 2005 9:29 AM

Michael said:

Interesting response. I myself think the question is very rudimentary and is a must-know, but I'm not so sure how long that will last. With ever-increasing levels of abstraction, there are side effects. One is that you can do a lot more with less depth of knowledge. Because of that, you're now expected to do a lot more, which means that even if you wanted to learn the nitty gritty details hidden beneath the surface, you just don't have the time. Like any resource... we immediately exhaust what we're given.

But on the flip side, even very high level abstractions of today are based on low level specifications, and that's not going to change. Going forward, you'll see developers who specialize at different ratios of breadth/depth. Those focused at the low level (say... those implementing network protocols for web servers) will have exceptional depth on the component that they manage (the HTTP protocol, for example), but may not know much about what their co-worker does. High-level devs will know how to integrate abstracted API's to build wide-scale web solutions, but won't know much about how HTTP actually works.

You see this today, but I forsee the divide becoming much worse. With the always advancing pace of technology, complexity will become so vast that the fore-mentioned solution devs won't be expected to understand HTTP at all. They'll be expeceted only to understand their abstracted frameworks, and believe me, that'll be quite a task in and of itself. Eventually, the protocol implementer and the solutions developer will just stare blankly at one another, as there will be 20 levels of frameworks seperating them.

Or maybe not. Thoughts?

# August 18, 2005 1:28 PM