If you are in IT, you have probably heard the term REST. Since it describes a popular design for modern applications, it is a common word nowadays. However, not all professionals know exactly what REST is and how does it work, but they should. REST is at the backbone of modern applications, and allow things that were not possible before. This is article is just about that, explaining what is a REST Architecture and how does it work. After that, if you have coding skills, you will be able to create your own RESTful application.
Introducing REST Architecture
What is REST?
We should start with the basics. REST is the acronym of Representational State Transfer, and it is a set of rules to make software-to-software communication standard. Think of it as a language, but spoken by the software when talking to another software. A REST Architecture is a web-service architecture, meaning it uses web protocols (HTTP, HTTPS) to work.
We can say that a RESTful application is somewhat a website accessed by software and programs, not people. Its pages have a clear and standard structure, and the requests that the software will make to it are standard as well.
Why REST?
In the end, all websites have the same purpose: transmitting, storing, and receiving information. However, they used to do also the job for the graphic interface as well. By using the REST Architecture, you strip out everything you don’t need. You focus on the content only and let the frontend application deal with the graphics. In other words, the same web-server, the same application, can serve a website, a mobile application, and more. If you are curious about structuring a website, take a look at this modern web application structure.
You are also ready to integrate third-party services and allow other developers to use your application. This creates enormous advantages. In the past, if an application did not suit a company, the company would build its own from scratch. It’s the Make-or-Buy decision. However, now the company can buy the essential core from you and then extend it to its need. They save time, and you still make money, a win-win.
Now, look at it from the other angle. In many cases, you might not be the one creating the RESTful application. Instead, you might use an existing application, being you the third-party. In any case, you always need to know what are the principles of the RESTful architecture.
Alternatives to the REST Architecture
If you don’t want to use the REST Architecture, you can use the SOAP Architecture. Both are valid strategies to design web services, except that REST is way better. REST is simpler, smaller, lighter, and can accomplish the same thing. SOAP is bulkier, as it uses a lot of additional meta-data. This means it is also slower, and harder to implement. In fact, developers are often preferring REST over SOAP. In this article, we won’t dive deeper into SOAP, and we will focus on the REST Architecture only.
Understanding the REST Architecture
The Resource
All the REST architecture is based on the concept of resource. A resource is an abstract representation of an item, mapped on a URL. This might sound complex at first, but it isn’t. Imagine you are writing a RESTful application that can host blog posts, the “post” can be a resource or something you want to expose for presentation or manipulation. A third-party application may call your application to list the posts, create a new one, or edit an existing one.
Virtually, everything can be a resource. For applications that run around a database, a resource is often a representation of a table. For others, it might be the representation of a class (in case of Object-Oriented Programming). Resources might also be fully abstract items, and there is no strict definition of what can be a resource, and what can’t.
However, all resources must have an URL mapping. This means you must be able to access them on a given URL. For our posts, it might be something like example.com/posts.
The Methods
Have you ever met the 404 Not Found error on a website? Probably, you had. This is because it is a standard error code for the responses of a website, so any website that doesn’t found a page will throw you that. However, HTTP does not standardize just this code: it gives standards for both request and response messages. A method defines the type of request you are making to the server, and not the response you are getting. The REST Architecture uses several methods, and each has a specific role.
| Method | Description |
|---|---|
GET | Retrieve the resource content or list all the resources. |
PUT | Replace the existing data with a new one, and generally create a new item if one doesn’t exist already. |
PATCH | Update existing data. Rarely implemented. |
POST | Create a new resource. |
DELETE | Delete a resource or an entire collection of resources. |
You always call the same URL, but with different methods. Based on the method, you do different things on the target resource. For example, GET /posts will list you all the posts, while GET /post/1 will give you the first post. Instead, you can create a new post with POST /posts/46 or delete it with DELETE /posts/11.
If you are curious about other HTTP methods, Mozilla is your friend. Not all methods are available as RESTful, and a RESTful resource doesn’t have to implement all the methods, not even all the methods listed above.
REST Architecture principles
Besides using resources and specific methods, a REST architecture must comply with six constraints. These principles dictate how the REST application should work.
- Client-Server – the separation of concerns must be clear. There must be a party that makes the requests (the client), and the other that gives the response (the server with the RESTful application).
- Statelessness – client context cannot be stored on the server. However, persistent states like authentication might be stored in a database, or re-authenticate every time.
- Cacheability – since the intermediary application may cache responses, the server must define each response as cachable or not. This can be implicitly as well.
- Layered – the client cannot identify if it is connected to the end server or an intermediary one, like a load balancer.
- Uniform Interface – the client must identify the resource in the request (in the URL) and use self-descriptive messages. The responses given by the server must provide enough data, including meta, to allow the client to do what it needs.
- Code on demand – this is an option and allows the server to send additional code to the client, typically JavaScript
Wrapping it up
In this article, we quickly covered how a REST architecture works, and how to use it. You are now free to implement it with any language you want, like Python or PHP. Instead, if you are accessing an existing REST application, Postman may help you with the debug.
What do you think about REST? Have you ever tried working with it, or with SOAP? Let me know your opinions in the comment.
