# HTTP - A Peak at REST's Concrete Implementation

HTTP is the protocol that allows for sending documents back and forth on the web. A protocol is a set of rules that allow for messages can be exchanged between two or more systems. A common protocol for example, is POP3, which is used to retrieve email from mail servers.

In HTTP, there are two different roles: the client and the server. In general, the client always initiates with a request and the server replies with a response. HTTP is text based; that is, messages are essentially bits of text, although the message body can also contain other media. Text usage makes it easy to monitor an HTTP exchange.

The HTTP ***request*** messages made by the client are made of a **verb**, a **header**, and a **body**. You may already be familiar with the verbs: `GET, POST, PUT, DELETE, PATCH`, and so on. The header contains metadata that describes the entire message. The body is where all the contents are stored.

For the HTTP ***response*** messages, they are made up of a **status code**, a **header**, and a **body**. Status codes range anywhere from the 100s to the 500s representing success to failures, they are an extra layer of metadata essentially.

![HTTP's Request - Response Cycle.](https://lh6.googleusercontent.com/8UYW_qRLmOhnyN9f76_i4nSX0LsI1GomMvM8g_vfQywS8IybIHMmVIk5VnwAvY1k--LvTlCOoze0Le4QO-NGUglAYNdEOrJFb5XyoGljtjfQ7uOKRkWPMRRszrlFKTTsSgPoMjY1)

## Relating HTTP to REST

In the previous section of the book, we went over the 6 categories of constraints of REST. Essentially, any protocol that adheres to those constraints would be considered to having a REST-based architecture. We will go over each of those constraints and see just how much HTTP innately adheres to them.

### **1. Client-server**

This is a simple one, we just looked at how HTTP has this request-response type of behavior, therefore the first constraint has been met.

### **2. Layered System**

There are many different layers that are in between HTTP. As stated previously: concrete examples are a cache layer, an API gateway layer, and a load balancer. This constraint has now been met too.

### **3. Cache**

In HTTP/1.1, we have mechanisms like 'ETag' and 'Cache-Control' which are built into HTTP. This means this constraint has been met also.

### **4. Stateless**

HTTP is stateless because each request is executed independently, without any knowledge of the requests that were executed before it, which means once the transaction ends, the connection between the browser and the server is also lost. So this would also mean that the stateless property is met as well.

### **5. Code-On-Demand (Optional)**

Nothing to say here, this was optional, so let's leave it at that XD.

### **6. Uniform Interface**

And now\... we move on to the most interesting constraint, uniform interface. In order to satisfy this constraint, we must first break it down to its four sub-constraints.

#### **6.1. Identification of resources**

How do we identify resources in HTTP? We use URIs.

#### **6.2. Manipulation of resources through representations**

Are we able to manipulative resources? Yes, we have metadata in the header to change to different formats like JSON or XML.

#### **6.3. Self-descriptive messages**

Same as above, we can use the metadata to manipulative information that can describe the message in different ways.

#### **6.4. Hypermedia as the engine of application state (HATEOAS)**

Now comes the tricky part, hypermedia. This essentially is where we, the developers, have to put in our effort to make our API truly RESTful. We will look more into this in the next section, but do note that this is the only (sub)constraint that HTTP ***does not provide*** with us out of the box.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://book.restfulnode.com/part-2/chapter-2/4-http-a-peak-at-rests-concrete-implementation.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.