Lay person’s guide to Representational State Transfer (REST)
What is Representational State Transfer (REST) and what are its benefits?
What is Representational State Transfer (REST) and what are its benefits?
Representational State Transfer (REST for short) is a communication/interaction model that was conceived by Roy Fielding in his doctoral dissertation Architectural Styles and the Design of Network-based Software Architectures. In this article, we will make an attempt to explain what REST is and how beneficial that communication/interaction model is. We will purposefully skip technical concepts and jargon and try to discuss REST from a lay person’s vantage point.
What is a protocol?
To understand the REST communication/interaction model, we first need to clarify the concept called ‘protocol’. In a nutshell, protocol denotes some form of formal communication.
OK, so what is a formal communication? Unlike the regular communication that occurs on a daily basis (usually called ‘informal communication’), formal communication is following certain predefined formal rules. For example, in many military situations, the rigid formal rules require participants to acknowledge the receipt and the understanding of the message or command by uttering the word “Roger”. In that context, the word Roger stands for “received”. That simple protocol often gets extended by adding the word “over”. When communicating, the person who is receiving the message/command can reply with “Roger over”, which means “I have received and understood the message and it’s over to you — I’m now listening.”
Why is protocol important?
Crisp and concise communication is essential for avoiding ambiguous situations and for keeping the confusion at bay. Informal communication is often muddled, ambiguous, open to interpretations. To make sure things don’t get messed up, we oftentimes resort to rigid formalized protocol when establishing the communication process.
What protocol is REST using?
As a formalized communication model, REST is based on the Hypertext Transfer Protocol (HTTP). That protocol specifies the mode of communication and interaction between physically separated systems. If we imagine one machine situated over there, and another machine situated over here, those machines are physically separated, but they may be capable of exchanging signals over the wire. That wire is called the network. Electrical signals flow through the network and get routed to the targeted machine. HTTP ensures that no wires get crossed, and that the signal reaches its intended destination.
Why do we need REST when we already have HTTP?
Seeing how HTTP ensures that the signal reaches its intended destination, we may ask why would that operation not be sufficient for correct communication/interaction? The reason for that is that it is not enough to just deliver the message and for the message to be fully received. Real communication/interaction occurs when the process of interpreting the message happens.
The interpretation of the received message is where HTTP as a communication protocol falls short. The unpacking of the meaning of the received message is the responsibility of the receiving party. In other words, when a machine (a computer, or a web browser) receives the message via the HTTP mechanism, it is up to that machine to decide what to do with the received message.
The message, as defined by HTTP, consists of two parts:
Request
Response
In the situation defined by the HTTP set of formal rules, a response cannot happen out-of-band. Meaning, the only way that one machine will prepare and send a response is if some other machine had triggered that process by first sending a request over the wire.
When a machine receives a request part of the message, it obliges the requestor by preparing the response. Once the response is formed, it gets sent back to the requesting machine.
Both machines, the requestor and the receiver who is responsible to prepare and then send the response, need to be able to understand the meaning of the message. From the requestor side, the request needs to be properly formulated and then sent to the appropriate location (i.e., the address on the network). From the receiver side, the arriving request needs to be unpacked and the intent of the request has to be interpreted. Based on that interpretation, the receiver will prepare the response and send it back to the requestor.
Finally, when the requestor receives the response, it needs to be able to unpack that response, interpret it, and then decide what to do next.
Prior to REST being formulated (i.e., prior to year 2000), the way the above described communication/interaction was happening was by supplying the out-of-band set of instructions on how to process the incoming request, how to interpret it, and how to prepare the response.
With the REST communication/interaction model, that out-of-band set of instructions becomes redundant. As such, REST communication/interaction model introduces a much more resilient way to accomplish the communication/interaction process. That feat is made possible by relying on the in-band information, meaning all the information necessary to process the request travels with the request itself.
This is still too technical; is there a simple, familiar example to clarify REST?
One way to look at the REST communication/interaction model is to compare it to the communication/interaction models implemented by modern bureaucracies. In this article we’ll take a quick look at how does a simple passport renewal process work:
Suppose I have a passport that is about to expire, and I want to renew it. I am not well versed in the bureaucratic procedure associated with the passport renewal. I am now wondering how should I go about doing it. I am a busy person, and I don’t have much time to study the process, so I am hoping that the government has come up with a simple way for me to accomplish the task.
Turns out I was right: the only thing I am expected to know before I embark upon the process of renewing my passport is the address of the nearest government passport office. I can get that address from the white pages or by doing a simple web search.
The knowledge of where to go to start the passport renewal process belongs to what we call out-of-band knowledge. That is something a requestor must know before engaging in the bureaucratic process, because without that knowledge, nothing can get triggered.
What happens next? Armed with the out-of-band knowledge, I visit the government office (I may do it by actually traveling there, or virtually — by visiting the government web site). Once there, all I need to do is obtain the brochure which will guide me on the steps I need to take to renew my passport. The knowledge contained in that brochure is what we call the in-band knowledge.
In the end, by following all the steps described in the brochure, I get to successfully renew my passport. It is important to note that throughout the passport renewal process, I did not have to reach out for any other piece of knowledge. All that was necessary for completing my request was exposed in the package containing the in-band information.
REST is no different than this bureaucratic procedure. The only thing necessary for the REST model of communication/interaction to commence is the knowledge of the entry point — i.e., which URL (which web address) does the requestor need to hit to be able to trigger the transaction. Once that out-of-band knowledge is obtained and acted upon, everything else unfolds thanks to the in-band information that is part of the request.
What are the benefits of the REST communication/interaction model?
Same as with the benefits I’ve enjoyed when following the bureaucratic passport renewal process, the benefits of using REST boil down to simplicity. Instead of having to work hard on obtaining some preordained information which would instruct the recipient on how to process the request (the out-of-band information), REST model provides that information in-band, i.e., it travels packaged with the request.
Not only is that arrangement freeing the consumer of the service from having to spend some time upfront to learn the ins and outs of how to interact with the service provider, it also frees up the service provider to continue honing their service offerings. We call such arrangement radical decoupling. What we mean by that is the two parties involved in the communication and interaction do not have to know anything about each other. As already mentioned, the only thing that the requestor needs to know is the entry point — the web address where the initial request needs to be sent.
Radical decoupling not only simplifies the process, it also makes it anti-fragile. Regardless of how much the service provider may change, the client requesting the services remains blissfully ignorant and remains ultimately unaffected by those changes. Given such arrangement, we see that REST enables turbulent and rapid evolving of the quality of the services without disturbing anyone’s ability to enjoy those ever improving services.
Conclusion
The problem with dependencies is that we cannot depend on them. Any time we are setting up a complex system that is supposed to provide sophisticated automated services, we inadvertently create dependencies. Clients who are in need of such sophisticated services are typically expected to obtain detailed knowledge on how to properly interact with the service provider (sometimes called the API documentation). To add more complications to such arrangement, once many clients become dependent on such elaborate knowledge, the service provider becomes a victim of their own success, in the sense of not being able to make much needed changes without breaking the established dependencies with the clients. And that creates a very undesirable brittleness.
REST is the communication/interaction model that proposes to minimize and even remove such dependencies. It offers a simple, elegant way to obtain just-in-time information on how to interact with the service provider. That way, the client/requestor need not waste time learning intricate rules of engagement, while the service provider need not worry about breaking any dependencies when making necessary and frequent changes.