Hello WebDevs,
I bet whichever framework you have been working on, you must have crossed your roads with API's and would have stuck for moment what should be the standard path for the URL you could use for that API.

Naming is the most difficult or brain consuming task for programmers, and when it comes to full url it becomes more difficult because they are not scoped by any block, they are all global and can be confusing if not used correctly.

For this Purpose some elite member of society ( Roy Fielding ) created a framework or architectural style called REST. It's very small concept but it becomes difficult when you start using it in real world project and brain consumption becomes equal. Hence I'm writing this blog to simplify the things for you, Let's Start.

What is REST?

REST(Representational State Transfer) is a standard that guides the design and development of processes for interacting with data stored on web servers. It simplifies communication by providing various HTTP methods (such as GET, POST, PUT, DELETE) that allow us to perform CRUD operations (Create, Read, Update, Delete) on server data. Think of REST as the set of rules that govern how we communicate with servers using the HTTP protocol.

In simple words,

It tells us how to change the state of our resource(db tables, files) on server with help of standard API pattern.

Here server means, machine from which we are requesting to change the state of our resources.

Now let's jump to real world example:

1. Fetch Data: Get Request

• If you want a list of items like list of users or post, or excel/csv containing list then we will always use Get request.
• If you want to filter or apply condition to the same list just use query parameters in get request.
• Even if you have large form for filter, try to pass only id's. but use get request. This will help you retain filter and pagination when you navigate back and forth on website.
• Example 1: /users/list?paginate=3&email=mr.yogesh.galav&name=yogesh
• Example 2: /users/:id/details
• Example 3: /users/:id/orders/csv

2. Create Data: Post Request

• It's the most common type of web request, but real purpose of this type is to create resources on server, like create db row, create user in registration, create token in login, create or save some file like profile pic/resume, etc.
• If you want some operation like createOrFind, updateOrCreate then also use post request.
• If you don't know what type of request it should be, but want to send lot of data to server like form data or file, then use this.
• Example 1: /users/create
• Example 2: /users/:id/orders/create
• Example 3: /users/:id/profile-pic

3. Update Data: Patch Request

• For updating resources on server Patch request is used. Most of the time we may think that create and update may share same controller or business logic, but as our business logic grows it becomes harder to maintain both at same place, hence a separate route/url with patch request is beneficial.
• If you want update some record on database on server then use this.
• Example 1: /users/update
• Example 2: /users/:id/orders/update

4. Replace Data: Put Request

• Unlike Database resources, files are generally replaced on server when it comes to update operation.
• If you want replace some file on server then use this.
• Example 1: /users/:id/profile-pic/replace

3. Delete Data: Delete Request

• This is most simple type of web request, as the name suggests, it is used to delete resources on server.
• If you want to delete some database record or file or token while logout use this.
• Example 1: /logout
• Example 2: /users/:id/delete
• Example 2: /users/:id/history/delete

These are only standards and not any hard and fast rule which will throw error somewhere so you can bend it like your choice but fundamentals should remain same so that url is clearly understandable without having to look into context or code.

Please Note that I have used suffix like create, details, update, replace, delete in above api's, It was personally easy for me to manage routes this way in framework, If you like not to use them then also fine, but then you had to take care of route ordering otherwise your framework will read

/users/create

as

/users/:id

I hope you enjoyed reading this.
Thanks & Regards,
Yogesh Galav