REST API (Representational State Transfer)

What is REST?

REST (Representational State Transfer) is a set of design principles used to build web APIs.

It defines how clients and servers should communicate over HTTP in a clean and predictable way.

Think of it like this:

HTTP gives us methods like GET, POST, PUT, DELETE.

REST tells us when and how to use them.

Why REST?

Without REST, every API could behave differently.

Example:

Instead of

GET /users/10

someone could create

POST /fetchUser

or

GET /get-user-data?id=10

Both may work, but every API would look different.

REST provides consistency.

REST Resource

REST treats everything as a resource.

Examples:

User
Product
Order
Comment
Invoice

Each resource has a unique URL.

Example:

/users
/users/10
/products
/orders/45

Notice these are nouns, not actions.

HTTP Methods in REST

REST uses HTTP methods according to their intended purpose.

Method Purpose Example
GET Read data GET /users/10
POST Create new resource POST /users
PUT Replace entire resource PUT /users/10
PATCH Update part of resource PATCH /users/10
DELETE Remove resource DELETE /users/10
--- ## Example Imagine a Book API.
GET /books

Returns all books.

GET /books/5

Returns book with ID 5.

POST /books

Creates a new book.

PUT /books/5

Replaces the entire book.

PATCH /books/5

Updates only specific fields.

DELETE /books/5

Deletes the book.

REST Principles (High Level)

1. Stateless

Each request contains everything needed to process it.

The server should not remember previous requests from the client.

Example:

GET /profile
Authorization: Bearer token

The token is sent with every request.

2. Resource-Based URLs

Use nouns instead of verbs.

Good

GET /users/15

Bad

GET /getUser

3. Standard HTTP Methods

Use HTTP methods according to their meaning.

Don't create APIs like

POST /deleteUser

Instead use

DELETE /users/15

4. Standard HTTP Status Codes

REST APIs use HTTP status codes to indicate the result.

Examples:

200 OK
201 Created
400 Bad Request
401 Unauthorized
404 Not Found
500 Internal Server Error

REST API Request Flow

Client
   │
   │ GET /users/10
   ▼
HTTP Request
   ▼
REST API Server
   ▼
Business Logic
   ▼
Database
   ▼
HTTP Response (JSON)

REST vs HTTP

HTTP REST
A communication protocol An architectural style
Defines methods, headers, status codes, message format Defines how APIs should be designed using HTTP
Can be used without REST Usually built on top of HTTP
--- # REST vs API An **API (Application Programming Interface)** is any interface that allows software to communicate with other software.

A REST API is simply an API that follows REST principles.

Examples:

So:

API
├── REST API
├── GraphQL API
├── SOAP API
└── gRPC API

Interview Summary

Idempotency

What is Idempotency?

An operation is idempotent if performing it multiple times has the same effect as performing it once.

In other words:

Sending the same request again does not change the final state after the first successful request.

Example 1 – GET (Idempotent)

GET /users/10

Call it once:

Returns user data

Call it 100 times:

Returns the same user data

The server's data never changes.

✅ Idempotent

Example 2 – DELETE (Idempotent)

DELETE /users/10

First request:

User is deleted.

Second request:

User is already gone.

The response might be 404 Not Found or 204 No Content, but the final state is still:

User does not exist.

✅ Still idempotent.

Example 3 – PUT (Idempotent)

Current user:

{
  "name": "John",
  "age": 25
}

Request:

PUT /users/10

{
  "name": "John",
  "age": 30
}

First request:

Age becomes 30.

Second request:

Still 30.

Nothing changes after the first update.

✅ Idempotent

Example 4 – PATCH (Usually Not Guaranteed)

PATCH /users/10

If the request is:

{
  "age": 30
}

Sending it repeatedly keeps the age at 30.

✅ This particular PATCH is idempotent.

But if the request is:

{
  "incrementViews": 1
}

Each request increases the count.

10 → 11 → 12 → 13

❌ Not idempotent.

So PATCH can be idempotent or non-idempotent depending on the operation.

Example 5 – POST (Not Idempotent)

POST /orders

Request:

{
  "product": "Laptop"
}

First request:

Creates Order #101

Second identical request:

Creates Order #102

Now two separate orders exist.

❌ Not idempotent.

HTTP Methods and Idempotency

HTTP Method Idempotent? Reason
GET ✅ Yes Only reads data
POST ❌ No Usually creates a new resource
PUT ✅ Yes Replaces the resource with the same data
PATCH ⚠️ Depends Depends on what it does
DELETE ✅ Yes After the first delete, the resource remains deleted
--- # Why is Idempotency Important? Imagine a client sends a request but the network times out before receiving the response.
Client
   │
POST /orders
   │
(Network timeout)

The client doesn't know whether the server processed the request.

For this reason, payment APIs often support idempotency keys (a unique identifier sent with the request).

If the same key is received again, the server returns the original result instead of processing the request twice.

Interview Summary