REST API Design Made Simple with Express.js
I remember the first time I heard the term REST API.
It sounded way more complicated than it turned out to be.
REST.
Resources.
Endpoints.
HTTP verbs.
Status codes.
It felt like too many words at once.
And honestly…
for a while I thought REST was some advanced architecture topic I’d understand much later.
But then someone showed me a simple example using users.
And suddenly…
it stopped feeling abstract.
It just looked like organized routes.
And that changed everything.
What I Thought APIs Were At First
I used to think APIs were something magical.
Like hidden systems talking behind the scenes.
Then I realized…
an API is often just a way for client and server to communicate.
Client asks for something.
Server responds.
That’s the core idea.
Simple.
And REST sits on top of organizing that communication.
What REST Started Meaning To Me
The explanation that helped me most was:
Think in terms of resources.
That word matters.
A resource can be:
Users
Products
Posts
Orders
Things your system manages.
And once I thought in terms of resources…
REST routes started making much more sense.
Example Resource: Users
Suppose resource is:
users
Now common operations become predictable.
Get users.
Create user.
Update user.
Delete user.
That is basically CRUD.
And that connects directly to HTTP methods.
That was my first “ohhh” moment.
CRUD vs HTTP Methods
GET — Read Data
This is usually fetching data.
Example:
GET /users
Get all users.
Or:
GET /users/42
Get one user.
Very straightforward.
In Express:
app.get(
"/users",
(req,res)=>{
res.send(
"All users"
);
}
);
That felt simple.
POST — Create Data
This one clicked when I stopped thinking of it as “send data.”
And thought:
Create something.
Example:
POST /users
Create a new user.
Express:
app.post(
"/users",
(req,res)=>{
res.send(
"User created"
);
}
);
Very common pattern.
PUT — Update Data
Example:
PUT /users/42
Update user 42.
That route shape started making sense once I noticed:
Resource.
Then specific resource ID.
Clean.
Consistent.
I liked that.
DELETE — Remove Data
Example:
DELETE /users/42
Delete user 42.
Pretty literal.
And honestly…
that consistency is part of what makes REST feel nice.
This Pattern Finally Looked Predictable
Same resource:
/users
Different method.
Different action.
That was huge for me.
Because suddenly API design looked less random.
And more structured.
I Used To Write Routes Like This
/getUsers
/createUser
/deleteUser
And I thought that was fine.
Then I learned REST style often prefers:
/users
/users/:id
And use HTTP method for action.
Much cleaner.
That was a big shift.
Designing Routes Using REST Thinking
Instead of naming actions in URL…
let URL represent resource.
And method represent action.
That’s the idea.
Example:
GET /users
POST /users
PUT /users/42
DELETE /users/42
Honestly…
once I saw that pattern…
I didn’t want to go back.
REST Request Response Flow
Status Codes Confused Me Too
At first I ignored them.
I thought:
If response comes back…
good enough.
Then I realized status codes matter.
They communicate result.
Very important.
The Basics I Remember
Success:
200
Okay.
Worked.
Created something:
201
Useful after POST.
Not found:
404
Very common.
Server issue:
500
Something went wrong.
That basic set got me started.
No need to memorize everything immediately.
Example In Express
app.get(
"/users/:id",
(req,res)=>{
res.status(200).json({
id:42
});
}
);
Simple.
But shows status plus response.
That matters.
This Made APIs Feel Like Conversations
Client says:
Give me user 42.
Server responds:
Here.
Status 200.
Data included.
That felt almost conversational.
And that helped me think about APIs differently.
One Mistake I Made
I thought REST meant using Express.
Not really.
REST is design style.
Express is tool you can use to implement it.
Different things.
I mixed those up early.
Another Mistake
I used verbs in routes too much.
Like:
/updateUser
Instead of:
PUT /users/:id
That took me time to unlearn.
Worth catching early.
Tiny Example Resource
app.get("/users",...);
app.post("/users",...);
app.put("/users/:id",...);
app.delete("/users/:id",...);
That small structure teaches a lot.
Honestly.
Why This Felt Cleaner
It reduced guessing.
If I see:
GET /products
I kind of know what it means.
That predictability matters.
Especially in teams.
And I think that’s why REST became so popular.
What Finally Made It Click
I stopped thinking:
REST is some complicated backend theory.
And started thinking:
It is just organizing routes around resources.
That made it simple.
Really simple.
Quick Recap
REST usually means:
Think in resources
Use HTTP methods for actions
Keep routes clean
Use status codes to communicate results
That’s the foundation.
Conclusion
For a long time…
REST sounded bigger than it needed to.
But once I saw it through one resource like users…
it became much easier.
Get users.
Create user.
Update user.
Delete user.
That’s the core.
And honestly…
a lot of REST starts there.
If you remember one thing from this article, remember this:
In REST, URLs usually represent resources…
and HTTP methods represent actions.
That sentence made it click for me.
If you like this simple learning-style explanation,
I write more notes at
devwithsahil.hashnode.dev
and share progress on LinkedIn 🙂
