The HTTP request/response Cycle with Rails MVC Architecture

Now that I’m more than halfway through my 15 weeks at Flatiron School’s bootcamp, I have started to review earlier parts of the curriculum. Technical interviews will be here before I know it, and it’s never too early to practice interview questions. In addition to understanding concepts, I also need to be able to succinctly convey those concepts while being put on the spot. Easier said than done!

One topic I recently revisited was the HTTP request/response cycle with a Rails backend. Seems simple enough: you type a URL into your browser, which sends information to the server. That info is then processed and, voila!, the server sends back the proper data to be displayed on your webpage. But there is a lot going on behind the scenes in the split second that it takes to pull up a webpage. In the hopes of grasping the cycle better myself, I’m going to lay it all out here so that you might gain some insight as well. Here we go!

1. HTTP Request

An HTTP request consists of 3 parts: a request line, headers, and a body. The request line includes the HTTP method, the URI (path of the resource) that you are trying to reach, and the HTTP version (1.1, 2.0, etc.). Headers are essentially metadata, or information about the request being sent, including things like cookies and authentication tokens. The final portion of the HTTP request, the message body, is optional. The body would contain information that is being sent to the server (aka “payload”), like form data or anything else that might need to be processed.

2. Server

This next section is specific to an MVC (Model View Controller) architecture like that of Rails. Other backend designs will have a different way of processing data. In Rails, however, the first stop for an HTTP request is the router. The router can be considered the “traffic cop” of the system. Depending on the specified method and path of the request, the router sends the request over to the corresponding controller. Controllers are essentially the decision makers, and they contain actions (methods) that are used to interact with models. The controllers send information to the appropriate model, which is a class that can query a database for the requested data. The data gets sent back through the controller and then on to the view, where the data is translated into HTML/JSON that can be rendered on the page.

3. HTTP Response

After the server has finished preparing an HTTP response, the response is sent back to the user. The response consists of 3 parts: a status line, headers, and a body. These are similar to the HTTP request, except the status line includes the HTTP version, a status code, and a status message. If all went well, you should get a status code of “200” and a status message of “OK”. The headers are once again metadata, except this time they describe the content of the response and how it should be handled by the user-agent. The body contains the resource data that was requested from the client. The client’s browser then renders the response data, and the cycle is complete!

What are your thoughts? Could you describe this cycle to a potential employer in an interview?