So far we've looked at quite a few pieces that comprise the modern Web. To this point we've seen what kinds of files are involved and the manner in which they are transmitted from server to client, but we have yet to see anything that would constitute a proper web application.

One of the key components that differentiates a web application from what we've yet seen is logic. Thus far we've only talked about web servers that stupidly obediently hand back files as they are requested, a process that requires relatively little logic and offers no variability.

So let's move on.

4.1 | Resources & Records

While actual files are certainly requested and sent over HTTP, the bulk of what we request on the Web today would be more accurately described as resources. Files themselves are actually considered resources, but they are static resources.

Say you visit someone's Twitter profile. Is the HTML you get back from the request just an HTML file that was stored by Twitter on a hard-drive somewhere and then simply passed to you over HTTP?

Certainly not.

When you request a given Twitter profile on twitter.com, you're requesting a dynamic resource.

The HTTP response body that results from the request will certainly contain HTML, but it is HTML that was pieced together when you requested it.

For instance, the tweets themselves (their text, author, creation time, etc) are persisted as records in a database and are then placed properly into HTML fragments which are in turn placed into the overall HTML document in the proper order. This process and those like it are one of the primary focuses of a web application, as well as one of the things that a web application framework, such as Ruby on Rails, aims to make easier for developers.

We'll be taking a much, much deeper look at this process once we get into Rails, but for now, more concepts!

4.2 | REST and CRUD

REST

REST stands for "Representational State Transfer" and is a style of accessing resources to be read, created, modified, and deleted over HTTP. REST offers a uniform means of access to all resources while employing HTTP verbs semantically.

Not all web applications are RESTful (not by any stretch), but Rails app aim to be.

As you might remember from our earlier example with the request to Google, our request used the GET method. GET is an incredibly common HTTP request method and is used all around the Web when we are simply asking for a page/resource.

I don't think you could get anymore semantic than "GET"; we want to get a web page, so we send a GET request.

...get.

To better understand REST and the other HTTP request methods, let's put all of this in context by using the chapters of this book as an example. The obvious place to start would be the very chapter we're on: how was it requested?

As you might expect, it too was requested using GET.

Let's then say that we wanted to create a new chapter. To do that, what kind of HTTP verb would we want to use to make the request?

That would be semantically suited by a POST.

Update a chapter? PUT request.

Delete a chapter? DELETE request.

Retrieve the Table of Contents (a list of all the chapter)? GET request.

CRUD

The types of actions we listed above, which happen to map nicely to REST, are commonly referred to as "CRUD" or "CRUDL", as defined below:

Letter Stands For Rails Action HTTP Verb
C Create create POST
R Read show GET
U Update update PUT
D Delete destroy DELETE
L Listing index GET

We'll be using the Rails terms pretty exclusively, but it helps to know what people are talking about when they mention "CRUD".

So now that we know which HTTP verbs to use for these actions, let's look at the paths.

The path, you'll probably remember, is the part of a URL after the domain and describes where something is relative to a server/service. For example, / is the path of the URL http://google.com/.

In Rails, paths are also referred to as routes because of the way they are handled in Rails. We'll get into all of that later, but for now we just need to know that "path" and "route" mean roughly the same thing in a Rails app.

Okay. Pulling all of the above together, we end up with the following set of routes:

HTTP Verb Route Action Result
GET /chapters index list all chapters
POST /chapters create create a chapter
GET /chapters/:id show retrieve a given chapter
PUT /chapters/:id update update a given chapter
DELETE /chapters/:id destroy delete a given chapter

So there you have it: RESTful Rails routes for resources.

Notice that there are five actions but only two unique routes:

  • /chapters
  • /chapters/:id

Anything in a route like :id, acts as a placeholder for a value, in this case an integer id. In the case of this chapter, the id is 4 and route is /chapters/4.

Wrap-up

Sure, REST, okay. That's all well and good, but why do we care about using a semantic HTTP verb for a given action? Couldn't we just use unique routes?

You absolutely could. People do.

But consider the following.

Let's say we wanted to delete a chapter with an ID of 123. In a system that is not RESTful, we could end up doing the following:

GET /chapters/123/delete

The server could receive this request and be programmed in such a way that it responds by destroying the proper resource. There are probably systems out there that do this or something similar, but there are two problems:

  1. Most glaringly, we are not really asking to get the resource, we are requesting that it be destroyed.
  2. The route /chapters/123/delete is unnecessarily long. The "delete" could be inferred from the DELETE HTTP request method and we could just reuse the /chapters/:id route to identify the resource to destroy. Furthermore, we could use it for updating a resource too (as RESTful systems do).

Some developers might be okay with this, but it's not the way we typically do things in Rails.

It is worth noting that Rails will offer two routes that are not, strictly speaking, RESTful:

  • GET /photos/new
  • GET /photos/:id/edit

More on this later.

In conclusion, Rails uses (mostly) RESTful routes for resource mapping which calls for just a few routes and utilizes HTTP verbs semantically to indicate what kind of action the client is requesting.

4.3 | Parameters

Remember way back in our look at HTML when we learned about <form> and submitting values to the server?

Well those values are referred to as parameters.

We've already seen the term "parameter" used in regards to the definition of a function, but it's used here too.

There are two types of parameters:

  1. query string parameters
  2. POST data

Query String Parameters

Query string parameters are dumped after the path in the following format:

?key1=value1&key2=value2

and placed after a path like this:

http://www.example.com/some/path?key1=value1&key2=value2

The ? signifies the beginning of the list of parameters, an = is placed between a corresponding key and value, and an & separates key/value pairs.

If we made a request to that hypothetical URL, the server would end up with a hash of the parameters that looks like this:

{
  key1: "value1",
  key2: "value2"
}

We'll take a better look at hashes when we get into Ruby, but as you can see above, JavaScript object literals are identical to hash literals.

An easy way to see a real example of this is to google "foobar". Look through the resulting URL and somewhere in there you'll see q=foobar. q here meaning "query".

There'll probably be a # instead of a ? though, because of the way Google uses Ajax to submit queries now.

But what if we want to use a literal = in our query string?

To do that we'll need to escape the =, much like we did with < and > with HTML entities. The way we do this for query strings is by using URL encoding

Also known as percent encoding.

What if, for example, we wanted to URL encode 2 + 2 = 4?

The resulting URL might look something like this:

http://www.example.com/some/path?equation=2+%2B+2+%3D+4

In the URL above, + represents a space, %2B represents a literal +, and %3D represents a literal =.

Dev Tools makes it easy to look at all of these as key/value pairs. Just request a page using query string parameters (e.g. perform a Google search), look at the request in the Network tab, and scroll down in "Headers" until you see "Query String Parameters".

Show screenshot.

POST Data

As the term "POST data" implies, it is only available for POST requests. As seen in the <form> example from the HTML section, the <form> can be submitted via POST.

  <form action="/some/path" method="post">
    <input type="text" name="key1" />
    <input type="text" name="key2" />
    <input type="submit" value="Submit" />
  </form>

Submitting the <form> above would result in the same hash server-side as we saw in the query string example, but would be accomplished instead by POST data.

POST data can be found within Dev Tools in the same general vicinity as where we just saw query string parameters.

Though <form> submission is the original means of sending POST data, there is now actually another means of accomplishing this from the browser: Ajax. Ajax serves other purposes besides this, but sending POST data is definitely one of its major responsibilities.

Sick of hearing about Ajax without an explanation? Good! Because it's up next.