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.
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:
When this is finished, the app sends an HTTP response back to the browser. The browser then displays the response to the user.
An HTTP request has three parts:
For this book, we'll only be concerned with the request line, and with two pieces of it in particular:
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 http://www.launchschool.com/books, /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.
HTTP Responses have three parts:
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.
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.