How a Request Becomes a Response

Talks

Christopher Greene

How a Request Becomes a Response

by Christopher Greene and Aimee Simone

In the video "How a Request Becomes a Response" presented by Christopher Greene and Aimee Simone at RailsConf 2013, the speakers explore the intricacies of the request/response cycle in a Ruby on Rails application. The focus is to help beginners understand the behind-the-scenes processes that occur from the moment an HTTP request leaves a browser until a response is generated and returned.

Key points discussed in the video include:

- Initiation of Request: The journey begins in the browser where a user enters a URL, such as 'codeschool.com/courses', triggering a GET request.

- Request Components: Understanding the elements of a request is essential. These include:

- Request Path: Specifies the resource being sought (e.g., 'courses').

- Request Verb/Method: Indicates the action (e.g., GET, POST, PUT, DELETE).

- Query Data: Additional parameters in the URL (e.g., '?page=2').

- Header Data: Information specifying desired formats and user details.

- Role of Web and App Servers: Once the request is made, it is handled first by a web server (e.g., Nginx, Apache) and then passed to an application server (e.g., Passenger, Puma) which executes application procedures and initiates Rails.

- Routing in Rails: The request is routed based on the path and method to the appropriate controller and action (e.g., 'index' action of 'CoursesController').

- Controller Actions: Collects data related to the request and prepares it for rendering, which ties into models that fetch the necessary data from the database.

- Rendering Views: Once the data is collected, it is formatted into a view (e.g., HTML) and sent as part of the response body.

- Response Composition: The response includes headers that signal the type of response (e.g., 'text/html') and status codes (e.g., 200 for success, 404 for not found). The response body delivers the actual content that the user sees in the browser.

The presenters emphasized that by understanding each component from request initiation to response rendering, viewers can better comprehend how Rails applications function, providing them with the necessary vernacular and context to dive deeper into the subject matter. The session concludes with a recap of the entire process, illustrating how seamlessly the various components interact to deliver web applications to users.

00:00:16.560 Hey guys, good morning! I'm Christopher Greene, or Chris Green, or whatever you want to call me. This is Aimee Simone. We're with Indy Labs and also with Code School. We have come to give you a little presentation about how requests become responses. It's going to be a kind of journey from the browser through the generation of a request, through the web server and app server, all the way up through the Rails stack, and back down to the client.

00:00:36.399 We'll touch on a lot of things, but we won't get into how to do this in detail. In the workshop section, you'll have access to Rails for Zombies and Rails Zombies 2, which will dive much deeper into how this stuff works. This presentation is more focused on understanding what is happening, how to trace it, and providing you with a vernacular—a nomenclature—so you can give this stuff context.

00:01:22.680 As Jeff mentioned, this is our workshop page. You can check out this page later; we will be posting our slides there. There's also a link to our chat room if you want to ask each other questions or answer questions during the session. Additionally, there are links to the materials we'll be using during the workshop. You won't need this right now, but feel free to pull it up if you'd like. We're going to go ahead and get started.

00:02:03.280 As Chris mentioned, we'll be following a request through the application stack. We'll start at the client, where the request is initiated in the browser, and follow it up through the Rails application until a response is formed. Then, we'll follow that response back through the stack to the browser.

00:02:34.040 So, what is a request? A request is a set of instructions that tells the server what kind of response we want. For example, this is the URL that you might type into a browser: 'codeschool.com/courses.' In our case, the request is made up of several different pieces that we need to understand. The first one I want to mention is the request path, which, in our example, is the 'courses' portion of the URL. This informs the server which resource we are looking for.

00:03:06.519 Next, we have the request verb or method. In our case, we're using a GET request, which retrieves information from our server. Other common request types include POST, which sends information to the server; PUT, which is similar to POST but updates information; and DELETE, which is self-explanatory as it removes information. We also have query data, which we could append to the URL. For instance, if we append '?page=2' to the request, it would let our application know we are looking for the second set of results, perhaps when using pagination. Lastly, we have header data, which contains a lot of valuable information.

00:03:56.000 In the request header, some important elements specify the desired response type; for instance, here, we might ask for 'text/html.' We also include information about the requester, such as language preferences, which in this case is English, and the user agent, in our example Mozilla running on a Mac—this is useful information.

00:04:47.600 Now that we've talked about the different pieces of a request, we will follow 'codeschool.com/courses' from the browser to the web server. Just a look ahead: we expect a particular response when we initiate our request. We are looking for a page on 'codschool.com' that returns a list of courses. So in our browser, we type 'codeschool.com/courses,' which initiates the GET request from the browser to the web server. So, what is a web server?

00:05:20.560 A web server delivers web pages when requested by clients using HTTP. It also handles the delivery of application content. In the Rails environment, some examples of web servers you might see or use are Nginx, Apache, and Puma.

00:06:06.400 Next, we're going to be following the request from the web server to the app server. Once we've made the request and the web server accepts it, it's passed on to the application server. An app server handles the execution of procedures for an application. We won't delve too much into all the intricacies of how this works right now, but it’s crucial to note that the app server initiates Rails.

00:06:49.080 Some common app servers you might encounter in a Rails application are Passenger and Puma. So, to recap, our request has moved from the browser to the web server, which accepted it, and now it is passed to the app server.

00:07:36.640 The request is now handed over to Rails. I've handed it over to Christopher, who will discuss how we further process this request.

00:08:11.960 So, as we've discussed, we've moved from the client to the web server, and it passes our request to the application server. Once the application server is initialized with the request, it leads to starting up Rails. When the request hits Rails, the first point it encounters is the router. The router tells the Rails application where to route this request.

00:09:02.399 For instance, the router uses the request path to find the relevant resources. Remember that our request was a GET to 'codeschool.com/courses.' This is what a 'routes.rb' file looks like.

00:09:19.679 In the routes file, we define routes. Don't worry too much about the specifics right now; just focus on the fact that we have a resource called 'courses', which will lead to a match for various actions such as 'index' and 'show.' You can run the command 'rake routes', which tells you what is defined in this routes file.

00:09:56.760 When the router sees a request with the GET method directed at the path of 'codeschool.com/courses,' it looks for the corresponding controller and action, which is the 'index' action in this case. This means we know that the index action on the courses controller is next in line. This part of the process allows the request to be routed to the correct action.

00:10:32.960 Next, let's briefly discuss controllers and what they do. Essentially, a controller combines actions related to a particular resource. For our example of 'courses,' the goal is to retrieve a list of courses. The actions that would concern us would be 'index,' 'show,' 'create,' and 'update.' The naming conventions in Rails mean we can identify the controller associated with 'courses' as the 'CoursesController.' The action we are focusing on, right now, is the 'index' action.

00:11:42.200 Actions in a controller are where we gather the necessary information regarding a specific request. In our case, we want to gather the list of courses and present that information back to the view to be rendered. This process lays the foundation for creating specific responses that will eventually be passed to the user.

00:12:15.360 Next, we'll briefly discuss models. A model is an abstraction of some business object or requirement, such as a user or a course. In our learning scenario, the model represents the 'Course' and contains the necessary data we need to present.

00:13:02.440 Thus, our 'Course' and 'Path' models are linked to the database and help pull in the relevant information needed for rendering. This is how a controller action relates to a model—essentially, a model serves as a bridge, fetching data that the controller can then manipulate before rendering it to a view.

00:13:51.080 Moving up the stack, once a request is made, the web server processes it, passes it onto the app server, and initiates the Rails application. The app server then allows Rails to start its processes, which include analyzing the request, formatting the data, and preparing it for render.

00:14:36.640 Once Rails collects its data, we prepare to render a view. In our example, the view might be expected in certain formats such as HTML or HAML, based on our rails application configuration. The action that handles this data preparation also passes it along for rendering.

00:15:32.120 Once the data is prepared, the view processes the information. This can be likened to a template or a mail merge, producing the necessary HTML output. Eventually, this HTML becomes part of the response body sent back to the client.

00:16:23.600 Next, we need to understand what makes up the response. Earlier, we discussed what a request entails, in terms of passing information about what we are asking. The response headers include important information indicating the type of data being sent back. For example, if we requested 'text/html', the response would include headers confirming the content type is 'html.'

00:17:30.960 The status code of the response also conveys crucial information about the success or failure of the request. Common status codes include 200 (OK), indicating successful processing; 404 (Not Found), signaling that the requested resource does not exist; and 500 (Internal Server Error), reflecting issues on the server side.

00:18:36.280 In addition to these, the response may include additional data such as cookies, which can be utilized for authentication, and more detailed error messages if something goes wrong during the processing.

00:19:01.560 Finally, the response body contains the actual payload, whether it's HTML content, JSON data, or another file type. This component of the response is crucial as it provides the data required for the browser to construct what the user sees.

00:19:53.640 At this point, we have traversed the entire stack—from the originating request in the browser, through servers and Rails processing, and onto constructing and returning the response back to the browser. We’ve detailed how each component plays a role in delivering a seamless experience.

RailsConf 2013