What is RESTful API

REST is an acronym for Resist Eating Stale-food Today…Nah just kidding but you gotta give me effort for coming up with that. REST is really an acronym that stands for REpresentational State Transfer. My version was better by the way. However, It is an architectural style that was first presented by Roy Fielding in 2000 in his dissertation.

Say Hi to Roy real quick 🤓🤓🤓🤓

For your REST API to be truly considered authentic “REST” you would have to follow 6 constraints. We’ll definitely touch on that shortly. The rules say we must satisfy these constraints for us to consider our interface as RESTful. Let’s get into it.

6 Constraints for REST

Client-Server 

This is the first principle we need to look at. Separation of concerns is the principle behind this constraint. When we separate the user interface concerns from the data storage concerns we make our systems more portable across multiple platforms. This also improves scalability by simplifying the server components. This separation allows each component to evolve independently of each other.

Stateless 

Adding to our client-server constraint, the communication between the client and the server must be stateless. What does the really mean? It means that each request from the client to the server must contain all the information that is required to understand the request. There shouldn’t be any data stored on the server-side in any sessions that can identify a request. The sessions for a user is kept entirely on the client side.

The disadvantage of this architectural choice is that the stateless constraint requires a design trade-off. The disadvantage is that it may decrease network performance by increasing the repetitive data sent in each requests.

Cacheable

Now it ain’t all rainbows and bubble gum. We gotta include other things to make up for the stateless disadvantage. This constraint speaks to the ability to be cacheable. In order for the improved network performance, we can add caching to form the client-cache-statelsss-server style. We would have to label the data that should be cached in the request. Utilizing caching allows us to remove some of the activities in handling a request, improving efficiency, scalability, and user-perceived performance.

Uniform interface

A uniform interface means creating a general interface for different types of requests versus a more specific one based on specific functionality. By creating a more general interface for clients to call we can make the overall architecture of the system simpler.

Layered system 

The layered system allows us to compose our architecture based on hierarchical layers in a way that separates different units of functionality. Each layer only communicates with the layer above and the layer below. By restricting knowledge of certain functionality to a single layer we make it easier to reuse functionality. Layers can be used to hide detailed functionality and provide some level of abstraction in the event an underlying technology needs to be changed. When this happens we don’t have to trouble our business logic.

The primary disadvantage of the layered system is that they add overhead and latency to the processing of data. However, caching can help offset any user-perceived performance

Code on demand (optional) 

Now, this constraint seems to be mistreated by the community, what you mean by optional. Yall treating “Code on demand” like a third-wheel. 😩😆 REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. Some people use it, some don’t.

Resources

The primary information in REST is called a resource. Basically, any information that can be named can be a resource. The general rule of thumb is that resources should be nouns and not verbs. The state of the resource at any time is called resource representation. A representation consists of data, metadata describing the data, and hypermedia links which can help the clients in transition to the next desired state.

Resource Methods

Resource methods are used to perform the desired actions on a resource. The method is the type of request you send to the server. You can choose from these four types below:

• GET: Retrieve details of a resource
• POST : Create a new resource
• PUT: Update an existing resource
• DELETE: Delete a resource

They are used to perform four possible actions: Create, Read, Update, and Delete (CRUD). Everything that is needed to change the resource state will be part of the API response for that resource.

Why use a RESTful API

Two words scale and loose-coupling, well technically three but ignore the “and”. With loose coupling, you can swap out components easily. This also makes your system more scalable as your system grows. Using loose coupling, you can safely write additional code when adding new features to your system without breaking the existing functionality. You can improve the client and the server independent of each other. You can create reusable server-side functionality for different applications i.e mobile, web, and desktop instead of re-inventing the wheel for each of these applications. This saves us a lot of time and money in the long run.

Final Thoughts

In this article, you learned what a REST API is and the different constraints that must be followed to completely create a RESTful API. We looked at why you would wanna use it as well. Hopefully, this gave you some useful insight into REST and how it might benefit your next project.