API Request Lifecycle — เมื่อกด Send เกิดอะไรขึ้นบ้าง?API Request Lifecycle — What Actually Happens When You Hit Send?

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

// Express.js example
app.get('/api/users/:id', async (req, res) => {
  const user = await db.users.findById(req.params.id);
  if (!user) {
    return res.status(404).json({ error: 'User not found' });
  }
  res.status(200).json(user);
});

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

{
  "id": 42,
  "name": "สมชาย",
  "email": "[email protected]",
  "role": "developer"
}

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGci...

{
  "name": "สมหญิง",
  "email": "[email protected]",
  "role": "student"
}

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/99

{
  "id": 99,
  "name": "สมหญิง",
  "email": "[email protected]",
  "role": "student",
  "createdAt": "2026-03-07T08:00:00Z"
}

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "Validation failed",
  "details": [
    { "field": "email", "message": "Invalid email format" }
  ]
}

# GET — ดึงข้อมูล
curl -X GET https://jsonplaceholder.typicode.com/users/1

# POST — สร้างข้อมูลใหม่
curl -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{"title": "Hello API", "body": "ทดสอบ!", "userId": 1}'

# DELETE — ลบข้อมูล
curl -X DELETE https://jsonplaceholder.typicode.com/posts/1

In the last post we talked about Docker, and how it lets us pack an environment so it behaves the same everywhere.

But when you open an app and press a button... have you ever wondered what happens between "pressing the button" and "getting the data back"? 🤔

That, right there, is the API Request Lifecycle — the process by which a Client (a website, an app) talks to a Server through an API.

---

What Is an API?

An API (Application Programming Interface) is a "channel of communication" between two pieces of software — like a waiter in a restaurant. You (the Client) order food through the waiter (the API), the order goes to the kitchen (the Server), and the waiter brings the food back to you.

💡 Easy way to remember: API = the waiter | Client = the customer | Server = the kitchen

---

How Does the API Request Lifecycle Work?

When a Client wants data from a Server, five steps take place — from the moment the Client sends the request to the moment the result appears in front of the user. All of it happens in a matter of milliseconds! Understanding this lifecycle makes debugging API issues far faster — "which step did the problem happen in?":

Step 1: The Client Sends a Request

The Client (a website, a mobile app, Postman) sends an HTTP Request to the Server, specifying:

• URL — the destination you want, e.g. https://api.example.com/users
• HTTP Method — what you intend to do (GET, POST, PUT, DELETE)
• Headers — extra information, such as an Authorization token
• Body — the data you attach (for POST and PUT)

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

Step 2: The Server Receives the Request

The Server receives the request but does not start working on it immediately — it passes through several "layers" first, like checkpoints: Middleware (auth checks, logging, rate limiting), Router (which handler does this URL belong to?), Validation (is the data correct?). Only if it clears all of them does it reach the handler function:

1. DNS Resolution — turns the domain name into an IP address
2. Load Balancer — spreads requests across whichever servers are free
3. Middleware — checks authentication, logging, rate limiting
4. Router — matches URL + Method to the correct handler

Step 3: The Server Processes

The handler function does the real work the request asked for — it may be as simple as pulling a record out of a database, or as involved as calculating prices, calling external APIs, sending email, or queuing background jobs. This step is where the "business logic" lives:

• Query data from the database
• Compute the business logic
• Call further external APIs (microservices)
• Validate the data

// Express.js example
app.get('/api/users/:id', async (req, res) => {
  const user = await db.users.findById(req.params.id);
  if (!user) {
    return res.status(404).json({ error: 'User not found' });
  }
  res.status(200).json(user);
});

Step 4: The Server Sends a Response Back

Once the processing is done, the Server builds an HTTP Response and sends it back to the Client — made up of a Status Code (success/failure), Headers (content type, cache, cookies), and a Body (the actual data, usually JSON):

• Status Code — reports the outcome (200, 404, 500, and so on)
• Headers — such as Content-Type, Cache-Control
• Body — the data being returned (usually JSON)

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

{
  "id": 42,
  "name": "Somchai",
  "email": "[email protected]",
  "role": "developer"
}

Step 5: The Client Renders

The Client receives the response, parses the data, and shows the result to the user — whether that is a web page, a mobile app, or a terminal.

---

HTTP Methods — What Can They Do?

HTTP has a number of methods, but five are used most of the time — matching the CRUD operations: GET (read), POST (create), PUT (replace everything), PATCH (change part of it), DELETE (remove). Choosing the right method is a RESTful best practice — not just using POST for everything!

Method	What it is for	Example
GET	Fetch data (read only)	GET /api/users
POST	Create new data	POST /api/users
PUT	Replace the whole record	PUT /api/users/42
PATCH	Change some fields	PATCH /api/users/42
DELETE	Delete data	DELETE /api/users/42

💡 CRUD Mapping: Create = POST, Read = GET, Update = PUT/PATCH, Delete = DELETE

---

HTTP Status Codes — What Is the Server Telling You?

Status codes are three-digit numbers that report the "outcome" of a request — grouped into five families by their leading digit: 1xx (informational), 2xx (success), 3xx (redirect), 4xx (client error — the fault is at the client), 5xx (server error — the fault is at the server). In DevOps you need the important ones by heart, because they are the first clue when an API misbehaves:

2xx — Success ✅

• 200 OK — it worked
• 201 Created — the new record was created successfully
• 204 No Content — it worked, but there is nothing to send back

3xx — Redirect 🔄

• 301 Moved Permanently — moved for good
• 304 Not Modified — go ahead and use your cache

4xx — Client Error ⚠️

• 400 Bad Request — the request is malformed
• 401 Unauthorized — not logged in yet
• 403 Forbidden — no permission
• 404 Not Found — nothing there
• 429 Too Many Requests — sending too often (rate limited)

5xx — Server Error 🔥

• 500 Internal Server Error — the server broke
• 502 Bad Gateway — a proxy or intermediate server has a problem
• 503 Service Unavailable — the server is overloaded or under maintenance

💡 Easy way to remember: 2xx = success | 4xx = the client's fault | 5xx = the server's fault

---

A Real Example — Creating a User with POST

Let's walk the whole lifecycle through a real example — the Client sends a POST request to create a new user; the Server validates the data, hashes the password, writes it to the database, and sends back a response carrying the user ID it created:

Request:

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGci...

{
  "name": "Somying",
  "email": "[email protected]",
  "role": "student"
}

Response (success):

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/99

{
  "id": 99,
  "name": "Somying",
  "email": "[email protected]",
  "role": "student",
  "createdAt": "2026-03-07T08:00:00Z"
}

Response (error):

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "Validation failed",
  "details": [
    { "field": "email", "message": "Invalid email format" }
  ]
}

---

Try It Yourself with cURL

cURL is a command-line tool for sending HTTP requests — in DevOps you reach for it constantly, to debug APIs, run health checks and write automation scripts. There are friendlier alternatives: Postman (GUI) and HTTPie (a CLI with nicer syntax than cURL). Go ahead and experiment against a public API:

# GET — fetch data
curl -X GET https://jsonplaceholder.typicode.com/users/1

# POST — create new data
curl -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{"title": "Hello API", "body": "Testing!", "userId": 1}'

# DELETE — remove data
curl -X DELETE https://jsonplaceholder.typicode.com/posts/1

🐕 Tip: Try HTTPie or Postman for API testing that is more convenient than cURL

---

Summary

The API Request Lifecycle is a foundation every developer has to understand — frontend, backend or DevOps alike. Every web app, mobile app and microservice communicates through APIs. Understand the lifecycle well = debug faster + design better APIs:

• API = the channel of communication between Client and Server
• Request Lifecycle = Client Request → Server Receives → Processes → Responds → Client Renders
• HTTP Methods = GET (read), POST (create), PUT/PATCH (update), DELETE (remove)
• Status Codes = 2xx success, 4xx the client's fault, 5xx the server's fault
• REST API is the most widely used style for designing APIs today