HTTP and Web Development Review

HTTP and Web Apps

In a lot of ways, building a web application is all about HTTP. This fact ends up getting obscured quickly as we dive into writing our application with a framework such as Ruby on Rails, but as you read, please try to keep in mind that the fundamental paradigm of a web application is to react to an HTTP request and to create an appropriate HTTP response. Much of what we'll see in Rails exists solely to make this easier.

Before we dive into building our application and learning about Rails, let's take a moment to review what we know about HTTP already, and begin to think about it in the context of developing a web application.

We expect you have read our Introduction to HTTP book at this point. If you haven't, you should take the time to go through it. It's a short read and provides the necessary background for this book.

The Client-Server Model

HTTP makes use of the client-server model. In the context of Rails web applications, the client is a web browser and the Rails app runs on the server.

Any interaction begins with the client (web browser) sending an HTTP request to the server (Rails app). The Rails app will then:

  1. figure out where to direct the request to be processed
  2. process the request with pre-defined logic
  3. construct a response

When this is finished, the app sends an HTTP response back to the browser. The browser then displays the response to the user.

Every Client-Server Interaction Begins with an HTTP Request

An HTTP request has three parts:

  1. request line
  2. request headers
  3. request message body

For this book, we'll only be concerned with the request line, and with two pieces of it in particular:

  1. the request verb (a.k.a. request method)
  2. the request path

GET and POST are common HTTP verbs, and /hello_world and /create_post are examples of paths.

The path is the part of the URL beginning with / that occurs after the domain. So for the URL, /books is the path.

Requests like the following will arrive in our web app:

GET /hello_world
POST /create_post

And based on the verb and path combination, we'll decide what to do with them.

Every Client-Server Interaction Ends with a HTTP Response

HTTP Responses have three parts:

  1. status code
  2. headers
  3. body

The status code tells the clients the general result of how the server processed the result. Some possible values are 200 (OK), 404 (Resource Not Found) and 500 (Server Side Error).

The headers tell the client how information from the response should be handled. They contain important metadata that the client can use to process a HTTP response. Some common response headers are Content-Type and Location; the former tells the client which type of information is being returned in the response and the latter is used in redirection by the client.

The body section of the response can be empty, but most of the time, there is a HTML document carried in the body section as "payload". This will be the primary HTTP response pattern we see in this book.

The Web Application in the Middle

Between the Request and Response is the actual web application that interprets the incoming requests, pulls the necessary data from the database, follows pre-defined business rules, and generates the responses that carry the HTML document to be displayed in the user's browser. Although it's possible to implement web applications from scratch without any frameworks, most modern web apps are built with frameworks like Ruby on Rails to make development easier.

We will learn the In's and Out's of how to build web applications with Rails in this book.

Let's get to it.