Quick Explanation of HTTP (Requests)

Introduction to HTTP and Its Origin
The creation of the first version of Hypertext Transfer Protocol (HTTP) occurred in 1991, with the credit going to Tim Berners-Lee and the developers who were part of his team at CERN. HTTP is a standardized way to transfer data (in the form of hypermedia documents) between a client side and a server side. Each side can be either a program or a machine that is connected to the Internet's World Wide Web. When utilizing HTTP, a client would send an HTTP request towards an URL on the Internet. The server located at this URL would then receive the request, process it, and then (depending on the type of request) perform an action on the server's data before sending back a HTTP response to the origin of the HTTP request on the Internet. This response would find its way back to the client and resolve as either a successful request that yields data of some kind, or an unsuccessful request that brings back an error message. To help visualize this process, I've made an analogy.

Analogy
You can visualize the client as a king and the server as a scribe who maintains a collection of information (which takes the form of all of the legal and historical records of the kingdom in this case). If the king wants a record stating what his kingdom's wealth was two years ago, he will have to write out a request (with the scribe's home address on it of course) to obtain said info from the scribe and send it out into the world on a carrier bird. This is similar to how a client sends a HTTP GET request to the URL of the server, with the request having headers describing the specific instance or type of data that the client is asking for. The scribe receives the bird's message, sees that it is a request from the king to get the kingdom's financial record from two years ago, and then proceeds to write out a copy of the desired financial record and sends it with the carrier bird back to the king. If the king's specifications were not correctly written or if the record doesn't exist, then the scribe would just send back a message saying what went wrong with the request. This is like how a client's http requests are received and processed by a server before the server either sends back a response containing the desired info for successful requests or sends back an error message (usually a generalized error code) that explains what went wrong with the request. Let's look at what at some HTTP request methods, shall we?

HTTP Request Methods
There are many different types of HTTP requests that do different things. As a rule of thumb, every request method receives a response that will be a result of either the request succeeding or the request failing. Here are some examples of request methods:

GET: Sends a request to receive certain data from a server and receives a response with a body containing the desired data from a server if successful.
POST: Sends a request to add the data from the request body to the data in a server.
PUT: Sends a request to take the data from the request body and to use it to replace some specified resource in a server.
DELETE: Sends a request to delete some specified data in a server.
OPTIONS: Sends a request to a server to respond back with some data that specifies what options are available for communicating with the server via HTTP request methods.
HEAD: Sends a request to receive certain data from a server and receives a response with headers relating to the desired data from a server. HEAD is like GET, but the response it receives lacks a body and the data that the request asked for.
CONNECT: Sends a request to create a "tunnel" that connects the client to the server and allows for continuous and automatic data transferring (which can be dangerous).
TRACE: Sends a request to a server that passes the request on to another server, which does the same thing until the desired server is found and sends a response back to the client. This response has a body stating what the last server in the chain received.
PATCH: Sends a request to take the data from the request body and to use it to modify some specified resource in a server. PATCH is similar to PUT, but PATCH only replaces part of the resource and not the entire resource.

Ok, so we have some HTTP request methods. How would we go about using them?

HTTP Requests General Structure (With Example)
HTTP requests (at least for requests utilizing HTTP version 1.1) usually consist of a start line, a collection of headers, an empty line, and a request body. I'll show you an example of a HTTP POST request and break it down from there.

Example of a HTTP POST Request:

POST /storage/people HTTP/1.1
Host: www.somewebsite.com
Accept: */*
Content-Type: application/json
Content-Length: 88

{
"name": "Bob",
"location": "Ohio",
"favoriteColor": "light-orange"
}

Start line (1st line of example): Contains the HTTP request method, the URL you wish to send the request to, and the version of HTTP you wish to use.

In the example, we have a POST method, followed by an URL of /storage/people (the website name is excluded from the URL for HTTP/1.1 requests), followed by an HTTP version of HTTP/1.1.

Headers (lines 2-5 of example): Resembles the key/value pairs in a JavaScript object. Each header is a word followed by a colon and some metadata that the header points to. The first few headers are request headers that provide some parameters for how the http request should be processed by the server. Any headers after the request headers (in this example) are the representation headers, and they allow the data in the request body to be translated into a different form (usually the data's original form) before being processed by the server.

The first two headers in the example are request headers. The Host header is required in HTTP/1.1, and it holds the website name, which is what would usually go in front of the URL in the start line. The Accept header tells the server what type of data it should try to send back in the response's body. Since the Accept header points to "/", the header is telling the server that the data in the response's body can be of any media type. The last two headers are representation headers. Content-Type tells the server what type of data is contained within the request's body, with this example request having JSON in its body. Content-Length tells the server how many bytes of data the request's body takes up. While this example's body takes up 76 bytes, the example's Content-length is 88 to give padding to help make sure that all of the request body is received by the server.

Empty line (line 6 of example): Is just and empty line signaling the end of the headers and the beginning of the body.

This is self-explanatory in the example.

Body (lines 7-11 of example): This part of the request is only needed for POST, PUT, and Patch requests. The body contains any data you wish to send to the server, with said data being used by the server to either modify an existing data collection with or to create new data collection within the server.

In the example, the body consists of a JSON object with key/value pairs. This JSON object would be expected to be added to the other people objects in www.somewebsite.com/storage/people, with the server sending back a success code of 201.

HTTP responses usually have the same type of general structure as HTTP requests. Among other small differences, the main difference with HTTP response structure is that has a status line instead of a start line. This status line consists of an HTTP version, a three-digit status code that indicates either a successful request or a failed request, and a bit of text that describe the meaning of the status code. Since this section has gone on for way too long, let's conclude this blog.

Conclusion
HTTP was first created by Tim Berners-Lee and his CERN team in 1991. HTTP standardized the way in which hypermedia is transmitted across the Internet. HTTP allows a client to send a response across the Internet to a server in order to GET data from, POST data to, or do something else with some data in the server. The server can process this request and send a response towards the client across the Internet that contains either a message indicating that the request was accepted (and perhaps also some data from the server's storage), or a message with an error code that indicates how the request failed.

Links to Sources Used