What a REST API really is - through a frontend dev's eyes

You have written fetch on the frontend and brought data in many times. Sometimes the data came as { data: [...] }, sometimes just as [...], and sometimes when an error happened the whole response looked different. Then for every endpoint on the frontend you had to think separately - and that mess is actually created by the backend. The backend's job is to shape the data so that the frontend person can understand what they got, what went wrong, and whether there is a next page of data.

The core rule of REST is very simple. Everything is a resource - like users, orders, products. And the HTTP method says what the action is: GET means fetch, POST means create new, PUT or PATCH means update, DELETE means remove. There will be no verb in the URL. Do not write /getUsers or /deleteOrder, because the method itself already says what the action is.

// Wrong - the action name in the URL
GET    /getUsers
POST   /createUser
DELETE /deleteUser/5

// Right - resource + method
GET    /users
POST   /users
DELETE /users/5

Keep the response format the same everywhere

The second important rule: every response must have the same shape. If one place has data, another has result, and another suddenly has payload, life becomes hard for the frontend team - and in interviews, this discipline is exactly what gets noticed.

app.get("/users", (req, res) => {
  res.json({
    success: true,
    data: users,
    message: "Users fetched",
  });
});

Status codes matter just as much here. 200 means OK, 201 means something new was created, 400 means the client's request is wrong, 401 means not logged in, 404 means not found, 500 means the server's own fault. The frontend takes many decisions by looking at the status code - so it is not just cosmetic, it is a signal.

Pagination, filtering, sorting - think from the start

If a user list has 10 thousand users, you cannot send them all at once. So list endpoints keep pagination like ?page=2&limit=20, plus ?search= or ?sort=-createdAt when needed. These decisions are easy to take on Day 1 and hard to add later - because by then the frontend is already used to the old format.

The mistake everyone makes

The most common mistake: sending a 200 status for every error and writing success: false inside. That breaks frontend error handling, and monitoring tools catch nothing. The status code is the first signal - if it is wrong, send the wrong status.

Today's practice

Set up a TypeScript + Express project in a new folder. Build 3 endpoints - GET /users, GET /users/:id, POST /users. Keep the same format in every response (success, data, message), use the correct status codes, and add pagination to the list with page and limit.

How to say it in an interview

REST means resource-based design - the URL holds the resource, the method says what the action is. I keep the same format in every response and use the correct status codes, so the frontend can decide by looking at signals instead of guessing.