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 statuses. In reality, HTTP is a very simple and effective protocol that anyone can understand.
Anatomy of an HTTP Transaction
Before getting started, let’s take a look at whats going on behind the scenes of an HTTP request. Let’s say you are visiting www.RickCarlino.com
An example 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 AJAX), your browser is only exchanging three things with the server.
An http REQUEST is divided into the following parts:
- A request line
- A request header
- 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:
- A status line
- Response headers
- The response body
If the server was set to not keep connections alive, the transaction is concluded. Often though, the connection will remain open to download any subsequent resources, such as CSS or images.
Let’s dig a little deeper.
The HTTP Request
This is what starts it all. Within the three parts of the request you will find:
The verb: In our case, we performed a GET request, which is a means of data retrieval. Many verbs 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 verbs, though others exist.
The path: This is the ‘R’ in URL. It 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.
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 status line is comprised of 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 meta data about the transaction or document. In our example, there is a ‘Content-Type’ header that describes the text encoding of the HTML document.
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 connection closes (unless it is a ‘Keep-Alive’ connection, 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 a wider use. Some of these include things like cookies, SSL encryption and compression.
Stay tuned for future blog posts where I examine and explore more of the foundations of HTTP. Sign up for my newsletter and get notified about new blog posts as they happen.