RESTful Architecture: An Introduction For Beginners

REST (REpresentational State Transfer) is an architectural approach to communications used in the development of web services. It’s a set of design principles to build web interfaces that can be used by virtually any device on any platform connected to the Internet.

Here in this post, I primarily tried to introduce readers to RESTful architecture which, I believe, would be helpful for keen learners, particularly those who are new to web technologies. If you consider yourself as one of them, you’re on the right track. First we'll know what REST is. And to do that, you gotta be a bit restless now, amigo.

Among many other architectural styles for client-server network communications, i.e- SOAP being the second most popular, REST is prefered mostly because of its simplicity and robustness. Despite being so lightweight, it’s highly scalable and easily maintainable which is why it’s so eminent among other architectural styles to create APIs for web applications. Proposed by Roy Fielding in his doctoral thesis in 2000 and embraced by Twitter in 2005, it’s been growing in popularity since then. Web services developed in this approach and the architecture itself are called RESTful.

So, what is REST actually? It’s a web standards based architecture which uses HTTP Protocol for data communication. It revolves around resource where every component is a resource and a resource is accessed by a common interface using HTTP standard methods. Resource can be text files, html pages, images or videos. In a RESTful manner, each resource is identified by URIs or global IDs. REST uses various representations to represent the state of a resource like plain text, JSON and XML. JSON is by far the most popular data format being used in web services, for it’s lightweight, robust and puts less payload on the bandawidth.

A simple illustration of a RESTful architecture has been shown below. You’re not expected to understand all of it, but have a quick look and read further to get to each of the components later on.

The most significant feature of a RESTful architecture is that it’s stateless. The server doesn’t store the state of clients it’s communicating to. This ensures less overhead (only the HTTP processing and XML/JSON parsing) on server allowing it to handle many clients at the same time with very little cost to pay. Since the clients and server are loosely coupled and independent of each other, greater scalability can be achieved. Though the state is held up in the client, the requests need to carry (transfer) all the information (state) the server needs to complete them making the requests a bit heavier, still it’s way more lightweight than other conventional architectures out there.

REST is a design principle built on top of HTTP. So there’s basically nothing in the web services that cannot be achieved using a RESTful architecture. Yet it’s simple, scalable and fully featured.

REST is platform and language independent. It's as secure as other approaches, can be carried over secure sockets using HTTPS and content can be encrypted. It can be used in the presence of firewalls. Last but not the least, performance and scalability can be greatly improved using proxy servers.

REST is all about request and response. Requests are made using simple verbs like get, post, delete, put etc. on nouns (a.k.a resources), pretty much like day-to-day human conversation. You want to do something on a resource, use a verb before it and send the request. Voila! Jobs will get done for you on the other side.

A RESTful architecture is designed using the underlying HTTP protocol. So, the basic methods for REST are same as those of the HTTP methods written in all caps. To be truly RESTful, an architecture must make sure the basic CRUD operations are executed using the following methods respectively:

1. POST: used to send data over the network, for example saving a record on the server. It’s the HTTP equivalent of Create. Let’s take this URL into account: /UserService/users/2. Requesting a POST on this URL may create a user with ID '2' on the server.
2. GET: used to request resource from the other end. This operation will get the user identified by the URL “/UserService/users/1” whose ID is '1'. This operation can be compared to Retrieve and it’s Read Only.
3. PUT: used to update a resource. This operation on the previous URL will update the user with ID '1'. Not to mention, this is the equivalent of update.
4. DELETE: as the name suggests, it deletes a resource. It will delete the user with ID '1' if operated on the previous URL in our example.

This pretty much sums up the RESTful architecture! Yeah, as simple as that, really. There are some other lately introduced methods like PATCH, OPTIONS etc, but, let’s save them for another post in the future so that you can take rest for a while until in the next post I discuss how to build a simple web application based on RESTful architecture. If you haven't heard of Play framework yet, that will be a good introductory post for you, I believe. So, stay tuned. Happy coding.