Let’s take some REST
It was a long day at work. Apart from doing my regular work of development I was involved in the process of technical hiring as well. When it comes to hiring a fullstack developer in 2018, one of the prominent question is: Can you REST?
So after all the hustle I did for the day, I though to take some REST and share the idea of REST to all of you. I will keep it short, crisp and to the point, not too easy not too advanced. If you are looking for a full blown article of REST, see this.
Let’s continue talking about REST APIs (From now on consider REST as REST APIs).
What is REST?
To be very clear, it’s all about sharing data between services. At the core, REST consists of a client (asking for something) and a server (responding with proper messages to the client). Read about the client-server model.
Why you need to REST?
- It’s easy to understand and easy to use
- It’s stateless.
- It can be cached
- It provides resource identification
How to REST?
So to REST, you need two primary information. Firstly, what action to perform and secondly on which resource you want to perform the action.
Now what the heck are ACTION and RESOURCE?
Everything in your application is a RESOURCE. Lets take an example of application which involves CRUD (Create, Read, Update, Delete) for users. For beginners, it’s an app that will help us in:
- Creating users
- Fetching all the users
- Updating users
- Deleting users
Our resource here is the User and the action(s) are the all the type of manipulations that we do with our users.
Coming back to the two primary information, they are the HTTP methods (the request method) and the resource URL (the request URL). More about HTTP methods
Thinking about REST
Enough about basics now. Real challenge people face when they try to REST is how to form a proper REST endpoint and give a proper name to it.
I will assume that you are good with the HTTP methods. I will show you when and how to use it along with naming resource address properly (yes the URL part I told you earlier)
What will be the first step you would like to do when making a CRUD app we spoke about? I would like to add a new user.
The HTTP method for adding a new record is POST.
Did that offended you? I am sorry then. Don’t scroll down and move to other articles. I will be brutal here.
So I have seen people using POST for creating, updating and even deleting resources. DO NOT DO THIS. Please stop doing this shit! I am aware of the fact that no one is forcing you to do so but there are few guidelines, please follow them for avoiding hazards.
So a proper endpoint (API) for different actions on user resource
- Creating new user: POST /users
- Getting all the users: GET /users
- Getting a particular user from all the users: GET /users/john or GET /users/123
(123 is the id of a particular user and jhon is username, whatever suits you. I will prefer username)
- Updating few things for a user from all the users: PATCH /users/john
(say if we only want to change the name to Johnny or his age or both name and age)
- Replace the existing user details: PUT /users/john
(Use PUT only when you want to update all the fields/properties of a resource)
- Deleting an user: DELETE /users/john
Are you relaxed now?
I have seen a lot pf people confusing between PUT and PATCH. Learn to use them wisely. I have already given you a hint for destroying this confusion. That’s almost the end of this post. I have left a lot of things related to REST, major one is HATEOS. I hope you will find this post helpful.
I will update this article with the following content:
- Response code you should send to your clients.
- Following a proper response format.
- Limitations of REST (Taking too much REST is bad!)