GET versus POST¶

The distinction between GET and POST arises in the front end, when we have to choose a method for our <form> elements, and it arises in the back end when we have to respond to different request methods. So, you might end up coming back to this reading from time to time.

Request Methods¶

The vast majority of web requests are trying to get an HTML page from the server, or, more generally getting a resource, whether an HTML file, CSS file, JS file, image file, bunch of JSON data or something like that.

Clicking on a hyperlink generates a GET request, as we saw with the hello-world.js Express app.

Some web requests are sending information to the server. When you post a comment or a picture to social media, you are uploading information to a server somewhere. That kind of web request is a POST request, or we say that the request is using the POST method.

POST and GET cover almost all HTTP methods. There are a few others that we will talk about later in the course.

GET and POST are similar, but they have some important differences.

GET versus POST¶

You may find it helpful to think of GET versus POST as the difference between sending information by either a postcard or a letter in an envelope.

• Both are ways to send information. GET and POST both send information from the browser to the server.
• The general term is a request. A request can use either GET or POST.
• GET and POST are different HTTP methods. (This is not "method" in the sense of object-oriented programming.) They are also sometimes called HTTP verbs.
• The two methods require slightly different handling by the sender and the receiver.

Forms and GET versus POST¶

One place this choice between GET and POST arises is HTML forms. For example, here is a form to request a map (like MapQuest or Google Maps):

<form action="/map" method="GET">
<label>street <input name="street"></label>
<label>city <input name="city"></label>
<label>state <input name="state"></label>
<label>zip <input name="zip"></label>
<input type="submit" value="map it!">
</form>

The goal of such a form is still to GET some information, but to get the correct map, the request needs to include a bunch of information, like street, city, state and zip code. So that information gets included in the request.

Another kind of form might be used to POST something, such as a comment form like this:

<form action="/comment" method="POST">
<label>username (optional) <br><input name="username"></label>
<label>comment <br><textarea name="comment" rows=3 columns=40 ></textarea></label>
<input type="submit" value="post comment!">
</form>

Try filling out and submitting the forms above. They both go to a special script that just reflects the data back to you, which is useful for debugging. (The action attributes above are pedagogical fibs; sorry.) You can look at the URL of the submitted form to see part of the difference in the format of the request:

• GET requests puts the form information in the URL
• POST requests put the form information in the body of the request (not shown)

We'll talk more about that in class.

Express and GET versus POST¶

What does GET versus POST have to do with Express? We can write handlers for both kinds of requests, just by using a different method:

app.get('/map', (req, res) => { ... });
// data in req.query

app.post('/comment', (req, res) => { ... });
// data in req.body

We will use POST in CS 304 but not right away. Still, since we've raised the issue, let's talk a bit about it now.

As indicated above, data submitted by the form is either in

• req.query if it was in the query string of a GET request, such as a form using the GET method
• req.body if it was in a POST request, such as a form using the POST method

Usage of GET versus POST¶

In addition to the differences in the format of GET and POST requests, there are also important differences in how and when they are used.

• GET is supposed to be used when reading information from the web server
• POST is supposed to be used when updating information on the web server

(If the distinction between reading data versus updating data reminds you of the difference between database queries using find versus modifying the state of the database using insert, update and delete, that's exactly right. We'll talk about that as part of this course.)

• The GET request to the /map route above might look up and return a map.
• The POST request to the /comment route above might insert the comment into a database collection.

These previous facts have some consequences:

With GET, since all the data is in the URL, and URLs aren't infinite in length, GET is unsuitable for long things, like submitting a blog post or uploading a file.

Because GET is for reading data, browsers and other computers can cache the results, rather that bothering the web server again. See below for more on caches.

Since all the data is in the URL, a GET request that retrieves something useful (such as helpful search results) can be bookmarked, saved in a browser history, emailed to a friend, etc. Google maps used to do this, and it was useful for sending someone a particular map or set of directions. So GET requests can be great in that situation.

If there is sensitive information being submitting (e.g. SSN or credit card number), having the sensitive information end up in the URL by using the GET method should probably be avoided, because URLs are sent in the clear (not encrypted) and are logged in the browser, server, and other places.

Because POST is for updating information, the browser will typically prevent you (with a warning) from re-submitting a form. This is a good thing. For example, you wouldn't want to accidentally resubmit an order to Amazon.com. But you should think about this. If re-submitting is harmless; don't use POST.

Here is a screenshot of an unnecessary warning I get when retrieving a classlist, because they used POST instead of GET:

All I did was try to "refresh" the page, to see if there had been any change in registrations. Had they used GET, that would have been fine, but because they used POST, I have to confirm this. This confirmation would be good if I was doing something like ordering a book; I don't want to pay for two copies just because I refreshed a page.

W3Schools has a very nice, concise summary of GET vs POST. I've copied some of it here, but go to their page if you'd like to learn more.

• GET requests can be cached
• GET requests remain in the browser history
• GET requests can be bookmarked
• GET requests should never be used when dealing with sensitive data
• GET requests have length restrictions
• GET requests are only used to request data (not modify)

and in contrast:

• POST requests are never cached
• POST requests do not remain in the browser history
• POST requests cannot be bookmarked
• POST requests have no restrictions on data length

Caches¶

Caches are an important part of the web browser and therefore are important to the web developer. We often made use of external CSS files and external JavaScript files. That allows multiple web pages to share those common files. Unfortunately, that would mean that each page has to request the external file, except that the web browser can cache the file. That means the browser says "I already have a copy of this file, so I don't need to request it." This saves time, network bandwidth, network connections and more.

So, let's understand more about caches.

The word “cache” (pronounced “cash”) is an ordinary, but uncommon, English word (more of an SAT word for most people). However, it's used all the time by computer scientists because caches are used all the time by computers, in all kinds of ways, because caching is a general technique for speeding things up. In particular, a cache speeds things up by storing to avoid re-doing.

Specifically, your web browser will cache (keep a copy of) files you visit or reference (images, external CSS, JS libraries, etc) in a folder on your local machine. (That folder is called, of course, the cache.) If the web browser needs that file again, say on another page of your site that uses the same external style sheet, the browser doesn't have to re-download the file; it just grabs a copy from the cache. This makes the web browser faster.

However, the browser cache can be a problem for a web designer, because if you make a change to the external style sheet or external JavaScript file, the web browser may continue to use the old cached copy, instead of getting the new improved copy from the server. This means that when you view your page, you won't see your changes — very frustrating.

The solution is to tell the web browser to ignore the cache when you re-load the page. In most web browsers, this is done by holding down the shift key when you click on the reload icon.

So, just remember:

When in doubt, use shift+reload