Lesson Monday

In the last lesson, we created a form that uses a POST request. If we'd wanted to, we could've used a GET request instead. However, it wouldn't be a good idea. In this lesson, we'll go over the difference between the two types of requests and when we might use GET versus POST in our forms.

Let's add a new form to our application to demonstrate the difference. Specifically, we'll add a form for searching albums because this is a common use case for using GET in a form. Note that we won't actually build out all search functionality — instead, that will be an optional objective in the next classwork project.

In views/albums.erb, go ahead and add the following form:

views/albums.erb
<form action="/albums">
  <div class="form-group">
    <label for="search">Search Query</label>
    <input id="search" name="search" class="form-control" type="text">
  </div>
  <button type="submit" class="btn btn-success">Search!</button>
</form>

Next, add a binding.pry to /albums in app.rb as well:

app.rb
get('/albums') do
  binding.pry
  @albums = Album.all
end

Next, let's navigate to the search form, enter "in rainbows" as our search query, and click "Search!". First we'll hit pry:

12: get('/albums') do
=> 13:   binding.pry
...

[1] pry(#<Sinatra::Application>)> params
=> {"search"=>"in rainbows"}

We have a key-value pair with a search key. So far, everything looks the same as our form with a POST request. Now exit pry and check the URL: http://localhost:4567/albums?search=in+rainbows.

The parameters we submitted are being passed through the URL. That's great for a search form but not very secure. For instance, if we needed to submit personal data about ourselves, we wouldn't want to pass that data through the URL. Anyone monitoring our application's web traffic would see it. It’s common for sites to cache URLs and we wouldn't want our bank account numbers stored in a URL where malicious users could find them.

Let's take a closer look at how our forms are different by opening Chrome Developer Tools and clicking on the Network tab. If we refresh the page with our search form (go ahead and remove pry), then submit a new search query like "Blue", we'll see a network request pop up.

Click on this network request, and we'll see a new window opened to a Headers tab. This shows a GET request with our search query. Notably, we can see the query parameter in the URL.

This image shows how we can use Chrome Developer Tools to see the request method, status code, and the data being passed in our application. In this case, we are looking at a GET request.

Next, select the Payload tab (within the Network tab).

GET request query string parameters in the DevTool's _Network_ tab.

Here we can also see our search query listed as part of the Query String Parameters section of the Network tab.

Now let's look at an example of a POST request in the Network tab when we add a new album.

This image shows how we can use Chrome Developer Tools to see the request method, status code, and the data being passed in our application. In this case, we are looking at a POST request.

Note that the form parameters are not found in the URL. If we look in the Payload tab, we'll see that the form parameters are passed through via form data:

POST request form data in the DevTool's _Network_ tab.

There's another reason we should favor POST for form data. If a route in app.rb expects parameters (such as a name for an album), our application will break if a user can simply make a GET request and enter the URL without adding parameters. In this case, any time a user or web crawler entered the URL, a new album without a name would be added to our mock database. That would be terrible.

That's why it's better to use POST for form data — a POST request can only be triggered by a form submission, and never by simply entering a URL into a browser.

In a very general sense, the difference between GET and POST requests is simple. We should use a GET request when we’re just retrieving data from a server. However, when we want to process data, we should use a POST request.

Usually we’ll process data by making some kind of change to a database. For instance, if we want to sign up for a newsletter, we’d submit a form, a POST request would be made to a server, and then a name and email would be added to a database.

When we start working with databases in the next course section, the difference between GET and POST requests will become even clearer.

We should use a GET request when we’re just retrieving data from a server. However, when we want to process data, we should use a POST request.

  • When we pass parameters through a GET request, they are passed in the URL. This is not secure.

  • A POST request has additional response and request headers and the form parameters are passed through via form data, not through the URL.

Lesson 20 of 37
Last updated August 7, 2022