What is REST?

You may have heard of REST and RESTful API and things like

“Your API should implement REST”

“Is your API is a REST API?”

So you have probably heard this term a lot, and you have probably heard it misused quite a bit, actually.

So lets talk about what is REST

Well, “REST is a set of architectural contraints“, such as

– Request are managed through HTTP. So for instance, you cannot have a REST service that uses another protocol besides HTTP.

– APIs or REST APIs need to be stateless client-server communication that means that the second call can’t depend on the first call having been made. So they have to be independent calls.

– So, you have to be able to cache data,not just require new data every single time, we can do that too.

– There has to be a uniform interface. Meaning it has to be pretty clear that how to get data out of your API so that it’s almost like, say self documenting code. that it’s easy to understand that you can gues as to what the API will do next.

There are more prohibitions besides these.

There’s a whole list of them

Things are layered system and potentially code on-demand and much more

But let’s talk about what really was REST? Where did it come from? And is it important?

So, REST was designed by Roy Fielding. And Roy Fielding was doing his PhD work. And Roy came up with REST, which he defined in his PhD dissertation. So, if you are familiar with PhDs,it is a doctorate program. It is a very complicated, very time-consuming, and very technical process for identifying that you know a subject very well.

And so his dissertation was on architectural styles and the design of Network based software architectures. So it’s all really complicated. And there he defined the REST structure.

Now, if you actually look at the original dissertation and what the original dissertation said for how REST was to be designed, you would find that almost no API today fully implements REST. There is a lot to REST, and it’s very theoretical in a lot of ways.

So here is my recommendation for you that you have to treat “REST as a design recommendation.“

You have not to worry about everything being perfectly RESTful. Otherwise, what happens is that you start building an API that doesn’t really work well.

You have to start building an API based upon a standard rather than based on what’s best for your API.

And yes, there is a balance there. But like with anything else, whether a design pattern, design practice, or principle, you need to make sure that you make the right choice for your application, not get stuck in making sure that your application is perfectly following a “rule.” because REST is a rule. It is not required to have an API that exactly follows REST.

And if you do have that requirement, your API is going to be difficult to create.

You have to make sure that your application is RESTful. It’s following the spirit of the law. So that means that you have standard HTTP verbs.

So, GET is a verb, and that’s for getting data. POST, and that is for creating data. and then we have PUT or PATCH, which are used for updating data. and we have delete, which is used for deleting data.

And you have to use those verbs appropriately instead of abusing the system.

because you could create an API that uses POST for everything. for creation, updates, and deletes, and it would work perfectly, but it wouldn’t be following the spirit of REST.

Because you don’t know, why would we do it this way versus that way? Why were you using POST for everything?

That’s not a great design.

So you should be clear about using the different HTTP verbs.

You are also going to have consistent naming, so for instance, you have to create users. So you have CRUD options on users, i.e., Create, Read, Update, and Delete; they will all be named /users because when you POST, you are creating a user, and when you Delete, you are deleting a user. and so instead of having endpoint that says “delete-user” and a different endpoint that’s “create-user” because thats a littile harder to underatsand and it is not consistent

So you have a good naming structure for APIs to make things work well.

*At last, repeating myself again, treat REST as a design recommendation, such as a design principle to follow, rather than a hard and fast rule.
*
If you have Comment or Suggestion please let me know in the comment section or mail me @ [e-mail]