If you’re learning web development, you’ve probably heard developers talk about REST APIs.

You may have seen endpoints such as:

GET /api/users
POST /api/users
GET /api/products/123
DELETE /api/products/123

But what exactly is a REST API?

How does it work?

And why do almost every modern web application use APIs?

In this beginner-friendly guide, we’ll understand REST APIs from the ground up with simple examples.

---

What Is an API?

Before understanding REST API, you need to understand what an API is.

API stands for Application Programming Interface.

In simple terms:

An API allows different software applications to communicate with each other.

For example, imagine you have a React frontend and a Node.js backend.

React Frontend
      ↓
     API
      ↓
Node.js Backend
      ↓
   Database

The frontend doesn’t usually communicate directly with the database.

Instead, it sends requests to the backend through APIs.

For example:

GET /api/products

The backend receives the request, gets products from the database, and sends the data back.

---

What Does REST Mean?

REST stands for:

Representational State Transfer

It is an architectural style for designing networked applications.

REST was introduced by Roy Fielding in his doctoral dissertation in 2000.

A RESTful API generally uses standard HTTP methods and represents application data as resources.

For example, in an e-commerce application, you might have resources such as:

Users
Products
Orders
Categories
Payments

Each resource can have a URL:

/api/users
/api/products
/api/orders
/api/categories

The client interacts with these resources using HTTP methods.

---

What Is a REST API?

A REST API is an API designed around REST principles and HTTP.

For example:

GET    /api/products
POST   /api/products
GET    /api/products/123
PUT    /api/products/123
DELETE /api/products/123

Each request tells the server what operation the client wants to perform.

You can think of it like this:

Client
   ↓
HTTP Request
   ↓
REST API
   ↓
Backend
   ↓
Database
   ↓
HTTP Response
   ↓
Client

---

How Does a REST API Work?

Let’s take a simple example.

Suppose you’re building an online shopping application.

A user opens the products page.

The frontend needs a list of products.

It sends:

GET /api/products

The backend receives the request.

It queries the database:

Database
   ↓
Find products

The backend then returns JSON:

{
  "products": [
    {
      "id": 1,
      "name": "Laptop",
      "price": 800
    },
    {
      "id": 2,
      "name": "Phone",
      "price": 500
    }
  ]
}

The frontend receives the response and displays the products.

The complete flow is:

User
 ↓
React App
 ↓
GET /api/products
 ↓
Node.js Server
 ↓
Database
 ↓
Products
 ↓
JSON Response
 ↓
React App
 ↓
Products displayed

---

HTTP Methods in REST APIs

REST APIs commonly use HTTP methods to describe what should happen to a resource.

The most important methods are:

• GET
• POST
• PUT
• PATCH
• DELETE

Let’s understand each one.

---

1. GET

GET is used to retrieve data.

For example:

GET /api/users

This might return all users.

You can also request a specific user:

GET /api/users/123

This means:

Get the user with ID 123.

Example response:

{
  "id": "123",
  "name": "John",
  "email": "john@example.com"
}

GET requests generally should not be used to modify server data.

---

2. POST

POST is commonly used to create a new resource.

For example:

POST /api/users

The client might send:

{
  "name": "John",
  "email": "john@example.com"
}

The server creates the user and might return:

{
  "id": "123",
  "name": "John",
  "email": "john@example.com"
}

So:

POST → Create

---

3. PUT

PUT is generally used to replace or completely update a resource.

For example:

PUT /api/users/123

Request:

{
  "name": "John Smith",
  "email": "john@example.com"
}

The server updates the resource.

A useful mental model is:

PUT → Replace/update the resource

---

4. PATCH

PATCH is generally used for a partial update.

Suppose a user only wants to change their name.

You could send:

PATCH /api/users/123

with:

{
  "name": "John Smith"
}

You don’t need to send every user field.

So:

PATCH → Partial update

---

5. DELETE

DELETE is used to remove a resource.

For example:

DELETE /api/users/123

This tells the server to delete the user with ID 123.

So:

DELETE → Delete

---

REST API Methods at a Glance

HTTP Method	Common Purpose	Example
GET	Retrieve data	GET /api/users
POST	Create data	POST /api/users
PUT	Replace/update data	PUT /api/users/123
PATCH	Partially update data	PATCH /api/users/123
DELETE	Delete data	DELETE /api/users/123

A simple way to remember them:

GET    → Read
POST   → Create
PUT    → Replace
PATCH  → Partially update
DELETE → Delete

---

What Is an API Endpoint?

An endpoint is a specific URL through which a client can interact with a resource.

For example:

GET /api/products

is an endpoint.

Other examples:

GET    /api/products
POST   /api/products
GET    /api/products/123
PATCH  /api/products/123
DELETE /api/products/123

Notice that the URL can be the same while the HTTP method changes the operation.

For example:

GET /api/products/123

means:

Get product 123.

While:

DELETE /api/products/123

means:

Delete product 123.

The HTTP method + URL together describe the operation.

---

What Is a REST Resource?

REST APIs are usually designed around resources.

For example, suppose you’re building a hospital management application.

You might have:

Patients
Doctors
Appointments
Hospitals
Payments

Your API could look like:

/api/patients
/api/doctors
/api/appointments
/api/hospitals
/api/payments

Each represents a resource.

For a particular appointment:

/api/appointments/123

The number 123 identifies the specific resource.

---

REST API and JSON

REST APIs commonly exchange data using JSON.

JSON stands for JavaScript Object Notation.

For example:

{
  "name": "John",
  "age": 25,
  "email": "john@example.com"
}

A frontend application can easily consume this data.

For example, JavaScript might receive:

const response = await fetch("/api/users");

const data = await response.json();

console.log(data);

The same API can potentially be consumed by:

• React
• Vue
• Angular
• Mobile applications
• Other backend services
• Desktop applications

That’s one of the reasons APIs are so useful.

---

Request and Response

Every REST API interaction generally involves a request and a response.

Request

The client sends:

HTTP Method
URL
Headers
Body

For example:

POST /api/users
Content-Type: application/json

with:

{
  "name": "John",
  "email": "john@example.com"
}

Response

The server might return:

201 Created

with:

{
  "message": "User created successfully",
  "user": {
    "id": "123",
    "name": "John"
  }
}

---

HTTP Status Codes

REST APIs use HTTP status codes to tell the client what happened.

Some common ones are:

200 OK

The request was successful.

GET /api/users
→ 200 OK

201 Created

A resource was successfully created.

POST /api/users
→ 201 Created

400 Bad Request

The request contains invalid data.

POST /api/users
→ 400 Bad Request

401 Unauthorized

Authentication is required or failed.

GET /api/profile
→ 401 Unauthorized

403 Forbidden

The user is authenticated but doesn’t have permission.

DELETE /api/users/123
→ 403 Forbidden

404 Not Found

The requested resource doesn’t exist.

GET /api/users/999
→ 404 Not Found

500 Internal Server Error

Something went wrong on the server.

GET /api/users
→ 500 Internal Server Error

---

What Does Stateless Mean in REST?

One important REST principle is statelessness.

Stateless means that each request should contain the information needed for the server to process it.

The server shouldn’t have to rely on remembering the state of a previous request to understand the current request.

For example, an authenticated API request might include a token:

Authorization: Bearer <token>

The server can use that token to identify and authenticate the request.

Conceptually:

Request 1
→ Contains required authentication information

Request 2
→ Contains required authentication information

Request 3
→ Contains required authentication information

Each request can be processed independently.

---

REST API Example With Node.js and Express

Let’s create a very simple REST API using Express.

const express = require("express");

const app = express();

app.use(express.json());

const users = [
  {
    id: 1,
    name: "John"
  },
  {
    id: 2,
    name: "Sarah"
  }
];

app.get("/api/users", (req, res) => {
  res.json(users);
});

app.get("/api/users/:id", (req, res) => {
  const user = users.find(
    user => user.id === Number(req.params.id)
  );

  if (!user) {
    return res.status(404).json({
      message: "User not found"
    });
  }

  res.json(user);
});

app.post("/api/users", (req, res) => {
  const user = {
    id: users.length + 1,
    name: req.body.name
  };

  users.push(user);

  res.status(201).json(user);
});

app.delete("/api/users/:id", (req, res) => {
  const index = users.findIndex(
    user => user.id === Number(req.params.id)
  );

  if (index === -1) {
    return res.status(404).json({
      message: "User not found"
    });
  }

  users.splice(index, 1);

  res.json({
    message: "User deleted successfully"
  });
});

app.listen(3000, () => {
  console.log("Server running on port 3000");
});

Now you have several REST endpoints:

GET    /api/users
GET    /api/users/:id
POST   /api/users
DELETE /api/users/:id

---

REST API With a Frontend

Suppose your frontend is built with React.

It can call the API:

const getUsers = async () => {
  const response = await fetch(
    "https://example.com/api/users"
  );

  const data = await response.json();

  return data;
};

The architecture becomes:

React
  ↓
REST API
  ↓
Node.js / Express
  ↓
MongoDB

This separation is extremely common in modern web applications.

---

REST API vs Website

A website and an API are not exactly the same thing.

A website might return HTML:

<h1>Users</h1>
<p>John</p>

An API commonly returns structured data:

{
  "users": [
    {
      "name": "John"
    }
  ]
}

The frontend application can then decide how that data should be displayed.

This allows the same backend API to serve different clients.

For example:

             REST API
                ↓
       ┌────────┼────────┐
       ↓        ↓        ↓
     Web      Mobile   Other App

---

REST API vs GraphQL

REST is not the only way to build APIs.

Another popular approach is GraphQL.

With REST, you might have:

GET /api/users/123
GET /api/users/123/orders

GraphQL commonly uses a single endpoint and allows clients to specify the data they need.

A simplified comparison:

REST	GraphQL
Multiple resource-based endpoints	Often a single endpoint
Uses HTTP methods	Uses queries/mutations
Simple and widely understood	More flexible data fetching
Easy to cache with standard HTTP mechanisms	Caching can require additional strategies
Common for traditional APIs	Useful for complex data requirements

Neither is automatically better.

The right choice depends on the application.

---

Common REST API Mistakes

1. Using Verbs in URLs

Avoid endpoints like:

/api/getUsers
/api/createUser
/api/deleteUser

A more RESTful design is:

GET    /api/users
POST   /api/users
DELETE /api/users/:id

The HTTP method already describes the action.

---

2. Using the Wrong HTTP Method

For example, don’t normally use:

GET /api/deleteUser/123

Use:

DELETE /api/users/123

This makes the API’s intent clearer.

---

3. Returning Incorrect Status Codes

Don’t return 200 OK for every situation.

For example:

201 → Created
400 → Bad Request
401 → Authentication required/failed
403 → Forbidden
404 → Not Found
500 → Server Error

Using appropriate status codes makes APIs easier for clients to work with.

---

4. Ignoring Validation

Never assume that incoming data is valid.

For example:

{
  "email": "hello"
}

Your API should validate whether the email is actually acceptable before storing it.

---

REST API Best Practices

When designing REST APIs, keep these principles in mind:

Use Resource-Based URLs

Prefer:

/api/products

instead of:

/api/getAllProducts

Use HTTP Methods Correctly

GET → Read
POST → Create
PUT/PATCH → Update
DELETE → Delete

Use Meaningful Status Codes

Return the status code that accurately represents the result.

Validate Input

Always validate request data before processing it.

Secure Your API

Use appropriate:

• Authentication
• Authorization
• HTTPS
• Rate limiting
• Input validation
• Security headers

Keep Responses Consistent

For example:

{
  "success": true,
  "data": {}
}

or another consistent response format across your API.

---

REST API in a Real Application

Imagine you’re building an e-commerce application.

You might have:

Users
Products
Orders
Cart
Payments

Your API could look like:

GET    /api/products
GET    /api/products/:id

POST   /api/products
PATCH  /api/products/:id
DELETE /api/products/:id

GET    /api/orders
GET    /api/orders/:id

POST   /api/orders
PATCH  /api/orders/:id

The frontend communicates with these endpoints.

The backend handles:

Authentication
Authorization
Validation
Business Logic
Database Operations

The database stores the actual application data.

---

The Complete REST API Flow

Let’s put everything together.

A user clicks “Create Account”.

The frontend sends:

POST /api/users

with:

{
  "name": "John",
  "email": "john@example.com",
  "password": "********"
}

The backend receives the request.

Then:

Request
   ↓
Middleware
   ↓
Validation
   ↓
Authentication/Authorization if required
   ↓
Controller
   ↓
Service
   ↓
Database
   ↓
Response

The API returns:

201 Created

with:

{
  "message": "Account created successfully"
}

The frontend receives the response and updates the UI.

---

Why Are REST APIs Important?

REST APIs are important because they allow different parts of a software system to communicate cleanly.

For example:

React
   ↓
REST API
   ↓
Node.js
   ↓
MongoDB

The frontend doesn’t need to know how the database works.

The database doesn’t need to know how the frontend looks.

The API acts as the communication layer between them.

This separation makes applications easier to develop, maintain, and scale.

---

Final Takeaway

A REST API is a way of designing APIs around resources, HTTP methods, and standard web principles.

The basic idea is:

Client
   ↓
HTTP Request
   ↓
REST API
   ↓
Server
   ↓
Database
   ↓
HTTP Response
   ↓
Client

The most important things to remember are:

GET    → Read
POST   → Create
PUT    → Replace/Update
PATCH  → Partial Update
DELETE → Delete

And REST APIs usually use resource-based URLs such as:

/api/users
/api/products
/api/orders

If you’re learning backend development, understanding REST APIs is one of the most important concepts you can learn. Once you understand how requests, responses, endpoints, HTTP methods, status codes, and resources work together, building applications with Node.js, Express, React, mobile apps, and other clients becomes much easier.

In simple terms: A REST API is a standardized way for applications to communicate with a server using HTTP.