2.1 URLs and Specs

For an application that runs on a server and transmits information across the internet (i.e. Software as a Service, SaaS), the interface consists of a set of Uniform Resource Locators (URLs) that a user can visit, and receive some information relevant and valuable to them.

Each URL will either:

  • display a page with some information (get in HTTP terminology)
  • trigger the storing of some information (post in HTTP terminology)
  • trigger the deleting of some information (delete in HTTP terminology)
  • trigger the updating of some information (patch in HTTP terminology)
  • forward to another URL
  • or some combination of the above

Most obviously, the user might be visiting the URLs in their browser by typing into the address bar or clicking on links. Or, more and more commonly, users might be visiting from native iPhone or Android apps without even knowing that, behind the scenes, they are visiting URLs to store and retrieve the information they need.

But make no mistake: if there is information being stored in a central database, then there’s a web server running somewhere and URLs are being visited with each action a user takes. When somebody puts that URL into the address bar and hits Enter, they are triggering a specific Ruby method.

In the background, there is a a noun (the object) and a verb (the instance method): Object#method Recall that Object#method notation symbolizes an instance method, while Object.method notation symbolizes a class method.. This method does the work of drawing the correct page of information for the user. Our job is to write those Ruby methods (called actions), and allow users to trigger them when they visit each URL.

We can write any Ruby we want in those action methods. We can generate random numbers, read from APIs, calculate things, send text messages, and more. But every action must do one of two things:

  1. Render a response, by sending back some HTML and displaying a new page

  2. Redirect, or forward the user onward to another URL.

And that’s everything that happens between the user visiting a URL and getting a response, it is a complete request lifecycle. Every URL is mapped to one Ruby method, and then we wire everything together so that Rails will listen for user visits. When someone visits a particular URL, then Rails will call the method we prepared, which will handle getting any database information, wrapping it in bootstrapped markup, and sending the HTML to the user’s browser.

You can fully specify a web application by listing out the URLs that users can visit, and what happens when each URL is visited. For example, let’s say we wanted to build an interactive game of Rock, Paper, Scissors. The complete specifications (or specs, for short) for this app might look like this:

  • http://[APP DOMAIN]/rock — Should display “You played rock.”, a random move by the computer, and the outcome.
  • http://[APP DOMAIN]/paper — Should display “You played paper.”, a random move by the computer, and the outcome.
  • http://[APP DOMAIN]/scissors — Should display “You played scissors.”, a random move by the computer, and the outcome.
  • http://[APP DOMAIN]/ — A welcome page that displays some information and the rules of the game.

Now — how do we get our web server to perform the above tasks when users visit the above URLs?

2.1.1 Quiz Question

  • What happens when a user in our app visits a URL from their address bar?
  • A Ruby Class is created for the page
    • Not quite, recall the term instance method
  • This URL is added to our specs
    • No, because we the developers specify the available URLs
  • A Ruby method connected to the URL is called
    • That’s right! This is the action method that does the work of rendering or redirecting {: .choose_best #bin points=“30” answer=“3” }