When I started backend development, I kept seeing terms like:

• HTTP methods
• GET, POST, PUT, PATCH, DELETE
• status codes
• headers
• REST
• statelessness
• idempotency
• resources

At first, they felt like a bunch of rules I just had to memorize.

But once I understood what actually happens when a browser or frontend talks to a backend, these concepts started fitting together.

This blog is my attempt to understand HTTP and REST as a conversation between a client and a server.

1. The Basic Idea: Client Talks to Server

Whenever we use an application, there is usually some communication happening between a client and a server.

For example, imagine a Twitter-like application.

I open my profile.

The frontend might send:

GET /users/123

The server processes the request and sends something back:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "name": "Koushik"
}

That's HTTP communication.

The basic pattern is:

Client
  |
  | HTTP Request
  v
Server
  |
  | HTTP Response
  v
Client

This is the foundation of most web APIs.

2. What Is HTTP?

HTTP stands for:

HyperText Transfer Protocol

It is a protocol that defines how clients and servers communicate.

A client could be:

• browser
• React application
• mobile app
• Postman
• another backend service

A server could be:

• Node.js server
• Express application
• NestJS application
• Java/Spring application
• Python/Django application
• Go server

The important thing is that both sides understand the HTTP rules.

3. The Request/Response Cycle

This is one of the most important concepts to understand.

Let's say I open:

GET /users/123

The process roughly looks like this:

1. Client creates request
          ↓
2. Request travels to server
          ↓
3. Server receives request
          ↓
4. Server finds the route
          ↓
5. Server runs application logic
          ↓
6. Server may query a database
          ↓
7. Server creates response
          ↓
8. Response travels back
          ↓
9. Client receives response

Let's go through it.

4. Step 1: The Client Creates a Request

Suppose my frontend wants to get a user.

It might send:

GET /users/123 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer token

This request contains information telling the server what the client wants.

5. Step 2: The Request Travels to the Server

The request travels over the network.

The client needs to know where the server is.

For example:

https://api.example.com/users/123

The browser or HTTP client handles things like:

• DNS lookup
• establishing a network connection
• TLS encryption for HTTPS
• sending the HTTP request

We don't usually think about all of these steps when writing backend code, but they happen underneath.

6. Step 3: The Server Receives the Request

Our Node.js application receives the HTTP request.

For example:

const http = require("node:http");

const server = http.createServer((req, res) => {
  console.log(req.method);
  console.log(req.url);
});

server.listen(3000);

If the client sends:

GET /users/123

we can access:

req.method

which gives:

GET

and:

req.url

which gives:

/users/123

7. Step 4: Routing

The server needs to figure out:

"What code should handle this request?"

For example:

GET /users
GET /users/123
POST /users
PATCH /users/123
DELETE /users/123

Each route can perform a different operation.

In a framework like Express or NestJS, routing becomes much easier to organize.

8. Step 5: Business Logic

Once the correct route is found, the application performs its work.

For example:

GET /users/123
        ↓
Find user 123
        ↓
Check permissions
        ↓
Fetch user from database
        ↓
Create response

The server might interact with:

• PostgreSQL
• MongoDB
• Redis
• another API
• file storage

9. Step 6: The Server Sends a Response

The server eventually sends something back.

For example:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "name": "Koushik"
}

The response tells the client:

"Here is the result of your request."

10. The Complete Story

So the entire process looks like:

Frontend
   |
   | GET /users/123
   ↓
HTTP Server
   |
   ↓
Router
   |
   ↓
Controller
   |
   ↓
Service
   |
   ↓
Database
   |
   ↓
Service
   |
   ↓
Controller
   |
   ↓
HTTP Response
   |
   ↓
Frontend

This pattern becomes very familiar when working with Node.js and NestJS.

11. HTTP Methods

HTTP methods describe what the client wants to do.

The most common methods are:

GET
POST
PUT
PATCH
DELETE

Instead of inventing URLs like:

/createUser
/getUser
/updateUser
/deleteUser

REST APIs generally use the resource name and let the HTTP method describe the action.

For example:

GET    /users
POST   /users
GET    /users/123
PATCH  /users/123
DELETE /users/123

The URL identifies the resource.

The method tells us what we want to do with it.

12. GET

GET means:

"Give me this resource."

Example:

GET /users/123

The server might respond:

{
  "id": 123,
  "name": "Koushik"
}

Another example:

GET /users

could return a list of users.

GET should generally be safe

A GET request should not change the server's state.

For example:

GET /users/123

shouldn't delete the user or change their name.

13. POST

POST is commonly used to create a new resource.

For example:

POST /users
Content-Type: application/json

{
  "name": "Koushik",
  "email": "[email protected]"
}

The server may create:

User ID = 124

and respond:

201 Created

with the new resource.

14. PUT

PUT is commonly used to replace a resource with a new representation.

For example:

PUT /users/123

{
  "name": "Koushik",
  "email": "[email protected]"
}

Conceptually:

Old User
   ↓
Replace with
   ↓
New User representation

PUT can also be used for an upsert-style operation depending on the API design, but the exact behavior should be documented.

The important idea is:

PUT represents replacing the target resource with the supplied representation.

15. PATCH

PATCH is generally used for a partial update.

Suppose the user currently has:

{
  "id": 123,
  "name": "Koushik",
  "email": "[email protected]",
  "age": 20
}

We only want to change the name.

We can send:

PATCH /users/123

{
  "name": "Koushik Maya"
}

Only the specified field needs to change.

So:

PUT
→ replace/update the complete representation

PATCH
→ partially modify the resource

In real APIs, the exact semantics of PATCH depend on the patch format and API design.

16. DELETE

DELETE means:

"Remove this resource."

Example:

DELETE /users/123

The server may respond:

204 No Content

There is no need to return the deleted user.

17. Quick HTTP Method Table

18. What Is Idempotency?

This word sounds complicated, but the idea is simple.

A request is idempotent if making the same request multiple times has the same intended effect on the server's state as making it once.

For example:

PUT /users/123

with:

{
  "name": "Koushik"
}

If I send it once:

User name = Koushik

If I send it five times:

User name = Koushik

The final intended state is still the same.

That's idempotency.

19. GET Is Idempotent

Suppose:

GET /users/123

I send it:

1 time → get user
10 times → get user
100 times → get user

The server's resource state should not change.

GET is therefore considered idempotent and safe.

20. PUT Is Idempotent

Suppose:

PUT /users/123

{
  "name": "Koushik"
}

Sending it repeatedly should leave the resource in the same intended state.

Therefore, PUT is idempotent.

21. DELETE Is Idempotent

Suppose:

DELETE /users/123

First request:

User exists
       ↓
Delete user

Second request:

User already deleted

The response may be different, such as 404 Not Found, but the intended final state is still:

User does not exist

Therefore DELETE is considered idempotent.

This is an important distinction:

Idempotent does not mean every response must be identical.

It means repeated requests have the same intended effect on the resource state.

22. POST Is Generally Not Idempotent

Suppose:

POST /orders

{
  "productId": 10,
  "quantity": 1
}

If I send it once:

Order #1001 created

If I send it again:

Order #1002 created

Now I have two orders.

So POST is generally not idempotent.

This is one reason duplicate POST requests can be dangerous for operations like:

• payments
• order creation
• account creation

Some APIs solve this with an idempotency key.

23. What About PATCH?

PATCH is more nuanced.

PATCH is not automatically idempotent.

It depends on what the patch operation actually does.

For example, imagine:

PATCH /users/123

{
  "name": "Koushik"
}

Repeatedly applying that update may result in the same state.

But imagine a patch operation meaning:

increase balance by ₹100

Repeating it could produce:

₹100
₹200
₹300

So PATCH can be idempotent or non-idempotent depending on its semantics.

24. HTTP Status Codes

When a server responds, it sends a status code.

For example:

200 OK

The first digit tells us the broad category.

1xx → Informational
2xx → Success
3xx → Redirection
4xx → Client Error
5xx → Server Error

The categories are more important to memorize than every individual status code.

25. 1xx — Informational

These indicate that the request has been received and the process is continuing.

You won't use these directly very often in typical REST API development.

26. 2xx — Success

This means:

"The request was successfully handled."

Common examples:

200 OK

General successful response.

GET /users/123
→ 200 OK

201 Created

A resource was successfully created.

POST /users
→ 201 Created

204 No Content

Successful request with no response body.

DELETE /users/123
→ 204 No Content

27. 3xx — Redirection

These indicate that the client may need to take another action or use another location.

A familiar example is:

301 Moved Permanently

This tells clients that a resource has permanently moved.

Another is:

304 Not Modified

which is commonly involved with caching.

28. 4xx — Client Errors

These generally mean:

"There is something wrong with the request from the client."

Common examples:

400 Bad Request

The request is invalid.

POST /users

with malformed or invalid input might result in:

400 Bad Request

401 Unauthorized

Authentication is required or the provided authentication is invalid.

A useful way to remember it:

"I don't know who you are."

403 Forbidden

The server understood who you are, but you don't have permission.

Think:

"I know who you are, but you're not allowed to do this."

404 Not Found

The requested resource doesn't exist.

GET /users/999999
→ 404 Not Found

409 Conflict

The request conflicts with the current state.

For example, trying to create a username that must be unique.

422 Unprocessable Content

The server understands the request format, but the submitted data fails validation or semantic rules.

29. 5xx — Server Errors

These generally mean:

"The server failed while trying to handle a valid request."

For example:

500 Internal Server Error

Maybe our application crashed while processing the request.

Other examples include:

502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

These are especially important when dealing with distributed systems and reverse proxies.

30. Status Code Mental Model

I find this easier to remember:

2xx
"Everything worked."

3xx
"Go somewhere else / use cached information."

4xx
"Your request has a problem."

5xx
"Something went wrong on the server."

31. HTTP Headers

Headers are metadata attached to HTTP requests and responses.

Think of them like labels attached to a package.

The package contains the actual content.

The labels tell us things about it.

For example:

Content-Type: application/json
Authorization: Bearer abc123
Cache-Control: no-cache

32. Content-Type

Content-Type tells the receiver what format the message body uses.

For example:

Content-Type: application/json

means:

"The body contains JSON."

A request might look like:

POST /users
Content-Type: application/json

{
  "name": "Koushik"
}

Other examples include:

text/plain
text/html
multipart/form-data
application/xml

This becomes particularly important when uploading files.

33. Accept Header

Although not in the original list, Accept is worth knowing alongside Content-Type.

Content-Type describes:

"What I am sending."

Accept describes:

"What I would like to receive."

For example:

Content-Type: application/json
Accept: application/json

This distinction is very useful when working with APIs.

34. Authorization

The Authorization header is commonly used to send authentication credentials.

For example:

Authorization: Bearer eyJhbGciOi...

The server can use the token to determine:

• who the user is
• whether the token is valid
• what the user is allowed to do

A common pattern is:

Client
  |
  | Authorization: Bearer token
  ↓
Server
  |
  ↓
Validate token
  |
  ↓
Identify user

Important:

Authentication answers "Who are you?"

Authorization answers "Are you allowed to do this?"

35. Cache-Control

Cache-Control tells clients and intermediate caches how a response may be cached.

For example:

Cache-Control: max-age=3600

This can indicate that the response can be considered fresh for a certain period.

Another example:

Cache-Control: no-store

means the response should not be stored by a cache.

Caching can dramatically reduce unnecessary requests and improve performance.

36. Headers + Body

An HTTP message can be thought of like this:

HTTP Request
├── Method
├── URL
├── Headers
└── Body

Example:

POST /users HTTP/1.1
Content-Type: application/json
Authorization: Bearer token

{
  "name": "Koushik"
}

And the response:

HTTP Response
├── Status Code
├── Headers
└── Body

Example:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 123,
  "name": "Koushik"
}

37. What Does Stateless Mean?

REST APIs are commonly described as stateless.

At first this sounds like:

"The server doesn't remember anything."

That's not quite right.

Stateless means:

Each request should contain the information necessary for the server to understand and process that request.

The server shouldn't have to rely on hidden conversational state from a previous request.

38. Example of Stateless Authentication

Suppose I make:

GET /profile
Authorization: Bearer abc123

The server validates the token and identifies me.

Then I make another request:

GET /orders
Authorization: Bearer abc123

The second request contains the authentication information it needs.

The server doesn't need to think:

"This must be the same person who called /profile five seconds ago."

Each request carries the required context.

39. Why Statelessness Is Useful

Imagine you have three backend servers:

             Load Balancer
             /     |     \
            /      |      \
        Server A Server B Server C

A user makes one request:

Request 1 → Server A

Another request might go:

Request 2 → Server C

If the request contains the necessary authentication/context, any server can process it.

This makes horizontal scaling easier.

40. Stateless Does NOT Mean No Database

This is an important distinction.

A stateless API can absolutely use a database.

For example:

Request
   ↓
API Server
   ↓
Database
   ↓
Response

The database stores persistent application data.

Statelessness is about request-to-request application state, not about whether the application has storage.

41. REST

REST stands for:

Representational State Transfer

The name sounds intimidating, but the practical idea is much easier.

REST encourages us to model our API around resources.

Examples of resources:

users
posts
comments
orders
products

Instead of thinking:

"What function should this URL call?"

think:

"What resource am I working with?"

42. Resource Naming

A good REST API usually uses nouns rather than verbs.

Prefer:

GET /users

instead of:

GET /getUsers

Prefer:

POST /users

instead of:

POST /createUser

The HTTP method already tells us the action.

43. Resource Naming Examples

Good:

/users
/users/123
/posts
/posts/123
/comments
/comments/456

Less REST-like:

/getUsers
/createUser
/updateUser
/deleteUser
/getAllPosts

The idea is:

HTTP Method + Resource URL

together describe the operation.

44. Collections vs Individual Resources

A collection represents multiple resources:

/users

A specific resource:

/users/123

So:

GET /users

means:

"Give me users."

While:

GET /users/123

means:

"Give me user 123."

This distinction becomes extremely useful when designing APIs.

45. Nested Resources

Sometimes a resource belongs naturally to another resource.

For example:

/users/123/posts

could mean:

Posts belonging to user 123.

Or:

/posts/456/comments

could mean:

Comments belonging to post 456.

But nesting should not become unnecessarily deep.

Avoid things like:

/users/123/posts/456/comments/789/likes/10

if a simpler resource structure communicates the relationship.

46. Plural Resource Names

A common convention is to use plural nouns:

/users
/posts
/orders
/products

This makes collection endpoints intuitive.

For example:

GET /products
POST /products
GET /products/10
PATCH /products/10
DELETE /products/10

47. URLs Should Identify Resources

One of the biggest ideas in REST is:

The URL should identify the resource, while the HTTP method describes the operation.

For example:

GET    /users/123
POST   /users
PATCH  /users/123
DELETE /users/123

We don't need five completely different URLs.

The resource is:

/users/123

The method changes what we want to do with it.

48. Query Parameters

Query parameters are useful for filtering, sorting, searching, and pagination.

For example:

GET /users?role=admin

or:

GET /posts?limit=20&cursor=abc123

The path identifies the resource:

/posts

The query parameters describe how we want the collection represented.

49. A Real Example: Social Media API

Let's imagine we're building a Twitter-like application.

Get posts

GET /posts

Get one post

GET /posts/123

Create a post

POST /posts

{
  "content": "Learning Node.js!"
}

Update a post

PATCH /posts/123

{
  "content": "Learning Node.js and NestJS!"
}

Delete a post

DELETE /posts/123

This is much easier to understand than creating action-based URLs for everything.

50. Putting the Whole Concept Together

Imagine I click:

"Create Post"

The frontend sends:

POST /posts
Content-Type: application/json
Authorization: Bearer token

{
  "content": "Learning Node.js!"
}

The server receives the request.

Request
   ↓
Routing
   ↓
Authentication
   ↓
Validation
   ↓
Business Logic
   ↓
Database
   ↓
Response

The server might respond:

HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-cache

{
  "id": 501,
  "content": "Learning Node.js!",
  "authorId": 123
}

Now almost every concept from this blog has appeared:

• HTTP
• request/response cycle
• POST
• headers
• Content-Type
• Authorization
• status code
• REST resource
• database
• response body

51. A Simple Mental Model

If I had to remember everything with one diagram:

                 HTTP
                  |
        ┌─────────┴─────────┐
        |                   |
     REQUEST             RESPONSE
        |                   |
   ┌────┴────┐         ┌────┴────┐
   |         |         |         |
 Method    Headers   Status    Headers
   |         |         |         |
  URL       Body      Body      Body
   |
   ├── GET
   ├── POST
   ├── PUT
   ├── PATCH
   └── DELETE

And REST gives us a way to organize the URLs around resources:

/users
/users/123
/posts
/posts/123
/orders
/orders/123

52. Quick Revision Cheat Sheet

53. Final Takeaway

The biggest thing I learned is that HTTP isn't just:

"GET gets data and POST sends data."

There is a much bigger picture.

A client sends a request.

The request has:

Method
URL
Headers
Body

The server processes it and sends a response containing:

Status Code
Headers
Body

HTTP methods communicate intent:

GET     → read
POST    → create/process
PUT     → replace
PATCH   → partially modify
DELETE  → remove

Status codes communicate the result:

2xx → success
3xx → redirection
4xx → client/request problem
5xx → server problem

Headers provide metadata:

Content-Type
Authorization
Cache-Control

And REST gives us a clean way to organize the API around resources:

/users
/posts
/orders
/products

Once this mental model is clear, frameworks like Express.js and NestJS become much easier to understand.

They aren't replacing HTTP.

They're giving us better tools for building applications that communicate using HTTP.

And that's the real foundation of backend development.