HTTP - A Peak at REST's Concrete Implementation
Last updated
Last updated
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.
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.
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.
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.
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.
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.
Nothing to say here, this was optional, so let's leave it at that XD.
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.
How do we identify resources in HTTP? We use URIs.
Are we able to manipulative resources? Yes, we have metadata in the header to change to different formats like JSON or XML.
Same as above, we can use the metadata to manipulative information that can describe the message in different ways.
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.
