Understand the six REST API constraints and use them to your advantage.
Understanding the REST constraints and making them work for you.
In my adventure of knowing about APIs (Application Programmable Interface) and developing them, I have seen that REST (REpresentational State Transfer) has been the most preferred by many. Why? Because it enables developers to implement features, deploy them, and scale them independently. In geek terms, it helps developers implement loosely coupled applications. As independent as it may seem, REST-based systems rely on the HyperText Transfer Protocol (HTTP) for interaction through the Internet.
I have built a few APIs and did some studies about the architectural constraints of REST, My brainchild is this: these constraints aim to increase the independence and scalability of components while minimizing latency and network connectivity. In other words, low cost for high performance when using these constraints.
Knowing this, it is obvious that these constraints of REST are present to enable us to build better APIs. Now what are these constraints and how can they provide the oomph your API needs?
Exploring the 6 Fundamental Constraints of a RESTful API
The 6 architectural constraints that make RESTful web services such a breeze are listed below:
Client-Server.
Stateless.
Cache.
Uniform Interface.
Layered System.
Code-on-Demand (this constraint is optional).
The tale of two friends, Client-Server
Bringing your attention to a friendly relationship between two people is quite an unfair arrangement, but it works perfectly.
Let me bring you to the tech space; the relationship between a client and server is explained thus:
A client is someone—the user of a system or app — who requests a resource(s), while a server is someone — API, a database, online storage, etc.—who holds the resources a client needs. The client only knows the path to request from the server and nothing else. That is, it does not know how operations are being carried out or how resources are stored on the server. Likewise, the server only knows the path to send a response—the resource—to the client.
Be aware that the client and server are not dependent on each other in the development stage. They can be implemented independently as long as the channel for interaction is not altered.
Focus on the present, Statelessness
When it comes to RESTful API web services, it is necessary that the client include all the information needed when making a request for the server to carry out the operation and return a response.
The idea of statelessness comes into play before the request is received and after a response has been sent. A bit fuzzy, right? Let me keep this succinct, the server is to treat every request as a new request and does not store any details of the request after a response has been sent. Think of this as each request renting its own AirBnB on the server.
Being stateless enables a lot of availability; the only drawback is when a client provides too much data that may require more bandwidth.
Two heads better than one?, Cacheable
It is important to know that cached data is not the same as data stored in the database. Well, the data is the same, but not the instance. A cache is like a spare memory that enables you to store frequently requested resource(s) to reduce the response time. That is, not every request will require you to query the database.
In REST, we should apply caching to resources when applicable. With caching, most client-server interactions are eliminated. It can be implemented on the client side or on the server.
The drawback of caching is that if it is not updated, it is possible for the client to receive outdated data.
Having a sustainable effort, Uniform Interface
Having a uniform interaction is one of the key things that enables REST to stand out among others. You must design a structure for your API and follow through. You should know how to properly arrange your resource, any single resource should not be too large and contain everything in its representation.
There are four guidelines for ensuring a uniform interface:
Hypermedia As The Engine Of Application State (HATEOAS): links must be provided for each response so that users can quickly find additional resources. Get more understanding about HATEOAS here.
Resource-Based: the individual resource is easily identified in the requests.
Self-descriptive Messages.
Manipulation of resources through representation: if the client has the authority to do so, it can change or delete the resource on the server using the representation it has of it.
Living like an Onion, Layered System
REST employs a layered system architecture where you can deploy the APIs on server X, store data on server Y, and authenticate requests on server Z.
There may be many intermediate servers between the client and the final server, but each tier only has knowledge of its own local layer. By facilitating load-balancing and supplying shared caches, intermediary servers can increase system availability.
Too generous? Code-on-demand
This is an optional constraint. It helps to know that, apart from sending XML or JSON to the client, you can send executable code or server-side scripts to support a part of the client.
BONUS: Rules of REST API
When creating your REST endpoints, there are certain things to keep in mind.
REST is based on the resource or noun instead of the action or verb based. Example: /api/users.
HTTP verbs are used to identify the action.
A web application should be organized into resources like users and then uses HTTP verbs like — GET, PUT, POST, and DELETE to modify those resources.
Always use plurals in URL to keep an API URI consistent throughout the application.
Send a proper HTTP code to indicate a success or error status.
Knowing these constraints and the rules above has made a major difference in how I write my APIs, There are probably other ways that are better than this, but this is what works for most.
If you enjoyed this read, please leave a comment and share it. Stay connected for more.
Let’s also connect on other platforms.