How Does the Web Work? A Guide to Routes

In my last post, I discussed two of the most fundamental and powerful tools in building websites: libraries and frameworks. But after we write these lines of code, how exactly does it work in the larger picture of the internet. For this example, we’ll be exploring the Ruby on Rails framework. So let’s discuss a quick overview on how the internet works for web development.

Via Medium

The breakdown is quite simple. Try to follow along and if you don’t understand at first, don’t worry we’ll dive deeper in a moment. The image above can be broken down into a series of steps.

  1. A client makes a request to the internet through their browser.
  2. The request, encoded with parameters in its URL, gets sent to a server that accesses the website with the corresponding domain name.
  3. The website application is then accessed. Its controller receives the request and requests information through the models.
  4. The model accesses and manipulates the information stored in the database and returns it to the controller.
  5. The controller provides that information to the View for rendering and sends that rendered webpage back to the client as a response.

The key to understanding how the internet plays a role, between our framework’s MVC architecture and the client requesting the webpage, is understanding routes.

Via Reddit

Routes (or the concept of routing) refers to how browser requests are handled by your web application. As mentioned in the overview, the most common request you’ll see in a web browser, the HTTP request, encodes parameters in its URL. That combination makes up the request that your controller will receive. The controller has a few actions or methods to call based off the request received: GET, POST, PATCH, PUT and DELETE. In HTML 5, the requests are only broken down as GET and POST requests, where PATCH, PUT, and DELETE are all considered variations of a POST request.

When the controller receives a GET request, it tells the view to render an HTML file. However, when it receives any other request, the convention is to manipulate the data based on the parameters received and redirect back to a page that is rendered by a GET request.

In the Ruby on Rails framework, those parameters are stored as key-value pairs in a hash called params. Params is a Ruby object that your controllers can access. There are three ways this hash is assigned key-value pairs. The first way is from the query string of a GET request. The second is from the form data of a POST request. And lastly, they can be assigned by the path in the URL. Query strings and writing parameters directly into the URL are very similar in the fact that they’re both encoded into the URL but let’s look at a few examples to explore the difference.

Example 1:

If you wrote the parameters as a query string, the convention would require a ‘?’ first before writing the key-value pair. If our HTTP request was:

http://www.example.com/?foo=1&boo=octopus”

then our parameters would be stored as:

params = {“foo” => “1”, “boo” => “octopus”}

Example 2:

To receive the parameters directly from the URL, rather than from the query, we would have to write a route that reflected where the key-value pair would come from. The key would be written in the route as a symbol and the value would then be defined by whatever is written in place of the key when the URL is requested. (As you can see, this method allows the params to be more dynamically written.)

If we wrote our route as:

http://www.example.com/coupons/:id”

and received a UTL request of:

http://www.example.com/coupons/4”

then our parameters would be stored as:

params = {“id” => “4”}

Example 3:

The final way to receive parameters is in forms rendered by a GET request. Those pages receive information written by the user and when submitted, the parameters are stored for use in POST requests.

But wait, what is “utf8” and “authenticity_token”? …”controller”? …”action”? If you check back to the example, you’ll notice we had more input tags than just the ones for “coupon_code” and “store”. It’s okay if you don’t understand what each key is pointing to, just understand that the key is obtained from the “name” attribute of your input tags. But what about the “controller” and “action” attributes?

To answer that question, we have to look back at our routes. Routes themselves are made up of a request verb and a URI pattern (how the URL will be written). They point back to your MVC model, specifically to the written method inside of your controller. Your parameters, written into your post forms, will keep track of where it is going.

*Note: In a GET request, parameters appear in the URL itself. In all variations of a POST request, the parameters can be found in the URL as well as the data form.

So to conclude, let’s simplify this idea with an analogy. Let’s imagine your website application was a series of trains, the views of your MVC, and the controller are a team of conductors. Each client’s browser is a possible location for the trains to go. Routes communicates to the conductors which location to go and which train to use. Following this analogy, parameters are the tracks that makes your website dynamic, allowing different trains to travel to the same location by branching off the main url.

Citations

  1. Guillen, B. (2016, January 23). Ruby on rails params[] hash explained? (A. Matthews, Ed.). Retrieved May 20, 2018, from https://teamtreehouse.com/community/ruby-on-rails-params-hash-explained Online Forum
  2. Kolowich, L. (n.d.). How to Reduce Your Website’s HTTP Requests. Retrieved May 20, 2018, from https://blog.hubspot.com/marketing/reduce-http-requests
  3. What is the difference between URL parameters and query strings? (n.d.). Retrieved May 20, 2018, from https://stackoverflow.com/questions/39266970/what-is-the-difference-between-url-parameters-and-query-strings?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

Originally published at nikestech.wordpress.com on May 23, 2018.