If you're just starting out in web development, HTTP can seem like a pretty magical thing. Hidden from view are things like headers, tokens, payloads and status codes. In reality, HTTP is a very simple and effective protocol that anyone can understand.

Anatomy of an HTTP Request

Before getting started, let's take a look at what's going on behind the scenes of an HTTP request. Let's say you are visiting

The above diagram shows an example of an HTTP request and response. NOTE: Some headers have been removed for the sake of simplicity.

When your browser downloads a page (or when you make an API call via Fetch, XMLHttpRequest, or similar tools), the request and response each have three high-level pieces.

An HTTP request is divided into the following parts:

1. A request line
2. Request headers
3. A message body (which is usually empty for GET requests, but often contains JSON, XML or binary file uploads for other types of requests)

In exchange for these three items, the server hands the following back to the client:

1. A status line
2. Response headers
3. The response body

After the response, this request-response exchange is complete. The underlying connection may close or be reused for later requests, depending on the HTTP version and connection settings.

Let's dig a little deeper.

The HTTP Request

This is what starts it all. In HTTP/1.x, the first part of the request is the request line. It contains three sub-components:

The method: In our case, we performed a GET request, which is a means of data retrieval. Many methods exist and vary based on their usage. For example, if we were trying to delete a document, we could send a DELETE request rather than a GET (given that the server has been configured to do so). POST, PATCH, PUT, and OPTIONS are some of the most commonly seen methods, though others exist.

The request target: This is often a URL path, such as /blog, that tells the server which file, page or API resource you wish to GET.

The HTTP version: This tells the server which version of the HTTP specification you would like to use for the request.

After the request line, there are one or two following parts:

Headers: these provide information like metadata and cookies. More information about headers and cookies will be provided in a future post.

A message body: In our example, this was left blank, which is common for GET requests. Had this been a file upload or a form submission (via POST), the user data would have been placed in this part of the request.

The HTTP Response

This is the finished product of the HTTP transaction. It bears some similarities with the request in that it is made up of 3 parts.

The Status Line: Similar to the request line, the HTTP/1.x status line has three parts. It has an HTTP version, a computer-readable status code and lastly a human-readable reason phrase. Here is a list of all the status codes, for those curious.

Response Headers: Like the request headers, they provide relevant metadata about the transaction or document. In our example, there is a Content-Type header that describes the media type of the HTML document and may also specify its character encoding.

Response Body: The most important part. This is where the document is. For web browsers, this is typically an HTML document that will be rendered by the browser. Once the document is sent, the response is complete. The underlying connection may be closed or reused, which will be discussed in a future post.

That's It?

Yes and no. These elements are the building blocks of the modern web. But with simplicity comes the need for greater flexibility. Through the years, many features have been added for greater functionality. Examples include things like cookies, TLS encryption and compression.

Stay tuned for future blog posts where I examine and explore more of the foundations of HTTP.