#HTTP Status Code สำหรับ API Testing

HTTP Status Code เป็นข้อมูลสำคัญที่ API ส่งกลับมาเพื่อบอกผลลัพธ์ของ Request ว่า สำเร็จ, ต้องเปลี่ยนเส้นทาง, Request มีปัญหา หรือ Server เกิดข้อผิดพลาด

สำหรับงาน API Testing การตรวจสอบ Status Code ถือเป็น Assertion พื้นฐานที่ควรทำทุกครั้ง เพราะช่วยยืนยันว่า API มีพฤติกรรมตรงตาม API Contract และ Business Rule ที่กำหนดไว้

#HTTP Status Code คืออะไร

HTTP Status Code คือรหัสตัวเลข 3 หลักที่ Server ส่งกลับมาใน HTTP Response

ตัวอย่าง Request

GET /api/users/1 HTTP/1.1
Host: api.example.com

Response

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

{
  "id": 1,
  "name": "Alice"
}

ในตัวอย่างนี้ 200 OK หมายความว่า Server ประมวลผล Request สำเร็จและส่งข้อมูลกลับมาได้ตามปกติ

#กลุ่มของ HTTP Status Code

HTTP Status Code แบ่งออกเป็น 5 กลุ่มหลัก

กลุ่ม ความหมาย ใช้บอกอะไร
1xx Informational Server รับ Request แล้วและกำลังดำเนินการ
2xx Success Request สำเร็จ
3xx Redirection ต้อง Redirect หรือใช้ Cache
4xx Client Error Request หรือสิทธิ์ของ Client มีปัญหา
5xx Server Error Server หรือ Service ฝั่ง Backend มีปัญหา

จำง่าย ๆ ได้ว่า

1xx = กำลังดำเนินการ
2xx = สำเร็จ
3xx = เปลี่ยนเส้นทาง
4xx = Client มีปัญหา
5xx = Server มีปัญหา

#1xx — Informational

Status Code กลุ่ม 1xx หมายถึง Server รับ Request แล้ว และกำลังดำเนินการต่อ

กลุ่มนี้พบไม่บ่อยในการทดสอบ REST API ทั่วไป

#100 Continue

ใช้แจ้งว่า Client สามารถส่ง Request Body ต่อได้

HTTP/1.1 100 Continue

มักเกี่ยวข้องกับ Header

Expect: 100-continue

#2xx — Success

กลุ่ม 2xx หมายถึง Request สำเร็จ เป็นกลุ่มที่ใช้บ่อยมากในการทดสอบ Happy Path

#200 OK

ใช้เมื่อ Request สำเร็จและมี Response กลับมา

ตัวอย่าง

GET /api/users/1

Expected

HTTP/1.1 200 OK

Test Case

Given มี User ID = 1 อยู่ในระบบ
When ส่ง GET /api/users/1
Then Status Code ต้องเป็น 200
And Response ต้องมีข้อมูลของ User ID = 1

#201 Created

ใช้เมื่อ Server สร้าง Resource ใหม่สำเร็จ โดยมักใช้กับ POST

POST /api/users

Request

{
  "name": "Alice",
  "email": "alice@example.com"
}

Expected

HTTP/1.1 201 Created

API อาจส่ง Header กลับมาด้วย

Location: /api/users/101

สิ่งที่ควรทดสอบ

Status Code = 201
Response มี ID ของ Resource ใหม่
ข้อมูลตรงกับ Request
Location Header ถูกต้อง หาก API Specification กำหนด

#202 Accepted

หมายถึง Server รับ Request แล้ว แต่ยังประมวลผลไม่เสร็จ

เหมาะกับงานแบบ Asynchronous เช่น

  • Generate Report
  • AI Processing
  • Video Processing
  • Background Job
  • Message Queue
  • Batch Processing

ตัวอย่าง

POST /api/reports

Response

HTTP/1.1 202 Accepted

{
  "jobId": "JOB-1001",
  "status": "processing"
}

ในการทดสอบควรตรวจ Workflow ต่อด้วย เช่น

POST /api/reports
        ↓
202 Accepted
        ↓
GET /api/jobs/JOB-1001
        ↓
status = completed

#204 No Content

หมายถึง Request สำเร็จ แต่ไม่มี Response Body

มักใช้กับ

DELETE
PUT
PATCH

ตัวอย่าง

DELETE /api/users/10

Expected

HTTP/1.1 204 No Content

ตัวอย่าง Test Case

When DELETE /api/users/10
Then Status Code = 204
And Response Body ต้องว่าง
And GET /api/users/10 ต้องได้ 404

#3xx — Redirection

กลุ่ม 3xx เกี่ยวข้องกับ Redirect และ Cache

#301 Moved Permanently

Resource ถูกย้ายแบบถาวร

HTTP/1.1 301 Moved Permanently
Location: https://api.example.com/v2/users

เหมาะสำหรับทดสอบ URL Migration หรือ HTTP → HTTPS

#302 Found

Redirect แบบชั่วคราว

HTTP/1.1 302 Found

ควรระวังว่า HTTP Client หลายตัว Follow Redirect อัตโนมัติ ทำให้ Tester อาจเห็น 200 ของปลายทางแทน 302

#304 Not Modified

Resource ยังไม่เปลี่ยนจากข้อมูลที่ Client Cache ไว้

มักเกี่ยวข้องกับ Header เช่น

ETag
If-None-Match
Last-Modified
If-Modified-Since

เหมาะกับการทดสอบ Cache Behavior

#4xx — Client Error

กลุ่ม 4xx หมายถึง Request มีปัญหา หรือ Client ไม่มีสิทธิ์ดำเนินการ

เป็นกลุ่มที่สำคัญมากสำหรับ Negative Testing

#400 Bad Request

ใช้เมื่อ Request ไม่ถูกต้อง เช่น

  • JSON ผิดรูปแบบ
  • Parameter ไม่ครบ
  • Data Type ไม่ถูกต้อง
  • Validation ไม่ผ่าน

ตัวอย่าง

{
  "email": "invalid-email"
}

Expected

HTTP/1.1 400 Bad Request

#401 Unauthorized

หมายถึง Client ยัง Authentication ไม่สำเร็จ หรือ Credential ไม่ถูกต้อง

ตัวอย่างกรณีทดสอบ

ไม่ส่ง Token
Token หมดอายุ
Token ไม่ถูกต้อง
API Key ไม่ถูกต้อง

Expected

HTTP/1.1 401 Unauthorized

แม้ชื่อ Status จะเป็น Unauthorized แต่ในทางใช้งาน HTTP โดยทั่วไป 401 ใช้กับปัญหา Authentication

#403 Forbidden

หมายถึง Client Authentication สำเร็จแล้ว แต่ไม่มี Permission

ตัวอย่าง

DELETE /api/admin/users/10

เมื่อผู้ใช้มี Role เป็น

USER

Expected

HTTP/1.1 403 Forbidden

#401 กับ 403 ต่างกันอย่างไร

401 = ยังยืนยันตัวตนไม่ได้
403 = ยืนยันตัวตนแล้ว แต่ไม่มีสิทธิ์

ตัวอย่าง

ไม่มี Token
→ 401 Unauthorized

มี Token ถูกต้อง แต่ Role ไม่อนุญาต
→ 403 Forbidden

#404 Not Found

ใช้เมื่อไม่พบ Resource

GET /api/users/999999

Expected

HTTP/1.1 404 Not Found

#405 Method Not Allowed

ใช้เมื่อ Resource มีอยู่ แต่ HTTP Method ที่เรียกไม่รองรับ

เช่น API รองรับ

GET /api/users

แต่ Client ส่ง

DELETE /api/users

Expected

HTTP/1.1 405 Method Not Allowed

#409 Conflict

ใช้เมื่อ Request ขัดแย้งกับสถานะปัจจุบันของ Resource

ตัวอย่าง

  • Email ซ้ำ
  • Username ซ้ำ
  • Resource Version ไม่ตรง
  • Duplicate Record

Expected

HTTP/1.1 409 Conflict

#415 Unsupported Media Type

Server ไม่รองรับ Content-Type ที่ Client ส่งมา

เช่น API ต้องการ

Content-Type: application/json

แต่ Client ส่ง

Content-Type: text/plain

Expected

HTTP/1.1 415 Unsupported Media Type

#422 Unprocessable Content

ใช้เมื่อ Server เข้าใจ Request แต่ข้อมูลไม่ผ่าน Validation หรือ Business Rule

ตัวอย่าง

{
  "age": -5
}

หรือ

{
  "startDate": "2026-10-10",
  "endDate": "2026-10-01"
}

Expected อาจเป็น

HTTP/1.1 422 Unprocessable Content

อย่างไรก็ตาม บาง API อาจเลือกใช้ 400 Bad Request จึงควรอ้างอิง API Specification เป็นหลัก

#429 Too Many Requests

หมายถึง Client ส่ง Request มากเกิน Rate Limit

Expected

HTTP/1.1 429 Too Many Requests

อาจพบ Header

Retry-After: 60

เหมาะกับการทดสอบ

  • Rate Limiting
  • Throttling
  • API Gateway
  • Quota
  • Anti-Abuse

#5xx — Server Error

กลุ่ม 5xx หมายถึง Server ไม่สามารถประมวลผล Request ได้สำเร็จ

#500 Internal Server Error

เกิด Error ภายใน Server

HTTP/1.1 500 Internal Server Error

ตัวอย่างสาเหตุ

Unhandled Exception
Database Error
Null Pointer
Application Crash
Programming Error

API ไม่ควรเปิดเผยข้อมูลสำคัญ เช่น Stack Trace, Password หรือ Internal Path ใน Response

#501 Not Implemented

Server ยังไม่รองรับ Functionality หรือ HTTP Method ที่ร้องขอ

HTTP/1.1 501 Not Implemented

#502 Bad Gateway

Gateway หรือ Proxy ได้รับ Response ที่ผิดปกติจาก Upstream Server

พบได้ในระบบที่ใช้

  • Nginx
  • Reverse Proxy
  • API Gateway
  • Load Balancer
  • Microservices

#503 Service Unavailable

Service ไม่พร้อมให้บริการชั่วคราว เช่น

Server Overload
Maintenance
Dependency Down
Pod ยังไม่ Ready
Database ไม่พร้อมใช้งาน

Expected

HTTP/1.1 503 Service Unavailable

#504 Gateway Timeout

Gateway รอ Upstream Service นานเกินกำหนด

HTTP/1.1 504 Gateway Timeout

พบได้บ่อยในระบบ Microservices และ Distributed Systems

#Status Code ที่ API Tester ควรจำ

Status ชื่อ Scenario
200 OK GET สำเร็จ
201 Created POST สร้าง Resource สำเร็จ
202 Accepted รับงาน Async แล้ว
204 No Content DELETE สำเร็จ ไม่มี Body
301 Moved Permanently Redirect ถาวร
302 Found Redirect ชั่วคราว
304 Not Modified Cache ยังใช้ได้
400 Bad Request Request ไม่ถูกต้อง
401 Unauthorized Authentication ไม่ผ่าน
403 Forbidden ไม่มี Permission
404 Not Found ไม่พบ Resource
405 Method Not Allowed HTTP Method ไม่รองรับ
409 Conflict Resource Conflict
415 Unsupported Media Type Content-Type ไม่รองรับ
422 Unprocessable Content Validation/Business Rule ไม่ผ่าน
429 Too Many Requests เกิน Rate Limit
500 Internal Server Error Server Error
502 Bad Gateway Upstream Error
503 Service Unavailable Service ไม่พร้อม
504 Gateway Timeout Upstream Timeout

#ตัวอย่างการออกแบบ API Test Case

สมมติ API

POST /api/users

Request Body

{
  "name": "Alice",
  "email": "alice@example.com",
  "age": 25
}

สามารถออกแบบ Test Case ได้ดังนี้

Test Case Scenario Expected Status
TC01 สร้าง User สำเร็จ 201
TC02 ไม่ส่ง name 400 หรือ 422
TC03 Email Format ผิด 400 หรือ 422
TC04 Email ซ้ำ 409
TC05 ไม่ส่ง Token 401
TC06 Token ไม่ถูกต้อง 401
TC07 ไม่มีสิทธิ์สร้าง User 403
TC08 Content-Type ผิด 415
TC09 ส่ง Request เกิน Rate Limit 429

Expected Status Code ต้องอ้างอิง API Specification ของระบบเสมอ

#ตัวอย่างการทดสอบด้วย Postman

ตรวจสอบ Status Code

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

สำหรับการสร้าง Resource

pm.test("User should be created", function () {
    pm.response.to.have.status(201);
});

ตรวจสอบ Response Body

pm.test("Response contains user id", function () {
    const jsonData = pm.response.json();

    pm.expect(jsonData.id).to.exist;
});

ตรวจสอบ Content-Type

pm.test("Content-Type is JSON", function () {
    pm.expect(
        pm.response.headers.get("Content-Type")
    ).to.include("application/json");
});

#ตัวอย่าง API Testing ด้วย Playwright

ติดตั้ง

npm install -D @playwright/test

ตัวอย่าง GET

import { test, expect } from '@playwright/test';

test('GET user should return 200', async ({ request }) => {
  const response = await request.get(
    'https://api.example.com/users/1'
  );

  expect(response.status()).toBe(200);

  const body = await response.json();

  expect(body.id).toBe(1);
});

ตัวอย่าง POST

import { test, expect } from '@playwright/test';

test('Create user should return 201', async ({ request }) => {
  const response = await request.post(
    'https://api.example.com/users',
    {
      data: {
        name: 'Alice',
        email: 'alice@example.com'
      }
    }
  );

  expect(response.status()).toBe(201);

  const body = await response.json();

  expect(body.name).toBe('Alice');
});

Negative Test

test('Unknown user should return 404', async ({ request }) => {
  const response = await request.get(
    'https://api.example.com/users/999999'
  );

  expect(response.status()).toBe(404);
});

#ตัวอย่าง API Testing ด้วย pytest

ติดตั้ง

pip install pytest requests

หรือใช้ uv

uv add --dev pytest requests

ตัวอย่าง GET

import requests

def test_get_user():
    response = requests.get(
        "https://api.example.com/users/1"
    )

    assert response.status_code == 200

    data = response.json()

    assert data["id"] == 1

ตัวอย่าง POST

import requests

def test_create_user():
    payload = {
        "name": "Alice",
        "email": "alice@example.com"
    }

    response = requests.post(
        "https://api.example.com/users",
        json=payload
    )

    assert response.status_code == 201

    data = response.json()

    assert data["name"] == "Alice"

#ตัวอย่าง API Testing ด้วย Robot Framework

ติดตั้ง

pip install robotframework
pip install robotframework-requests

หรือใช้ uv

uv add robotframework robotframework-requests

ตัวอย่าง

*** Settings ***
Library    RequestsLibrary

*** Test Cases ***
Get Existing User
    Create Session
    ...    api
    ...    https://api.example.com

    ${response}=    GET On Session
    ...    api
    ...    /users/1

    Should Be Equal As Integers
    ...    ${response.status_code}
    ...    200

Negative Test

*** Test Cases ***
Get Unknown User
    Create Session
    ...    api
    ...    https://api.example.com

    ${response}=    GET On Session
    ...    api
    ...    /users/999999
    ...    expected_status=404

    Should Be Equal As Integers
    ...    ${response.status_code}
    ...    404

#อย่าทดสอบเฉพาะ Status Code

การตรวจสอบเพียง

Status Code = 200

ยังไม่เพียงพอ เพราะ API อาจตอบ 200 OK แต่ข้อมูลภายในผิด

ดังนั้น API Test ที่ดีควรตรวจสอบหลายองค์ประกอบร่วมกัน

#1. Status Code

200
201
400
404

#2. Response Body

ตรวจสอบข้อมูลสำคัญ เช่น

{
  "id": 1,
  "name": "Alice"
}

#3. Response Header

เช่น

Content-Type: application/json

รวมถึง

Cache-Control
ETag
Location
Retry-After

#4. Response Time

ตัวอย่าง Requirement

Response Time < 500 ms

โดยควรกำหนดตาม SLA หรือ SLO ของระบบ

#5. JSON Schema

ตรวจสอบ

Required Field
Data Type
Nullable
Array Structure
Nested Object

#6. Business Rules

เช่น

balance ต้องไม่ติดลบ
User Role = USER ต้องลบ ADMIN ไม่ได้
endDate ต้องมากกว่าหรือเท่ากับ startDate

#ไม่ควร Assert แบบกว้างเกินไป

ตัวอย่าง

expect(response.status()).toBeGreaterThanOrEqual(200);
expect(response.status()).toBeLessThan(300);

หาก API Contract ระบุว่า

POST /api/users

ต้องตอบ

201 Created

ควรตรวจโดยตรง

expect(response.status()).toBe(201);

เพราะ 200 OK และ 201 Created แม้จะอยู่ในกลุ่ม Success เหมือนกัน แต่มีความหมายต่างกัน

#HTTP Method กับ Success Status ที่พบบ่อย

HTTP Method Status Code ที่พบบ่อย
GET 200
POST 200, 201, 202
PUT 200, 204
PATCH 200, 204
DELETE 200, 202, 204

อย่างไรก็ตาม ควรยึด API Contract เป็นหลัก ไม่ควรเลือก Expected Status จาก HTTP Method เพียงอย่างเดียว

#Checklist สำหรับ API Tester

[ ] Happy Path
[ ] Invalid Input
[ ] Missing Required Field
[ ] Invalid Data Type
[ ] Authentication
[ ] Authorization
[ ] Resource Not Found
[ ] Duplicate / Conflict
[ ] Unsupported Content-Type
[ ] Rate Limit
[ ] Server Error Handling
[ ] Response Body
[ ] Response Header
[ ] JSON Schema
[ ] Business Rules
[ ] Response Time

#กำหนด Status Code ใน OpenAPI

ทีมพัฒนาควรกำหนด Expected Response ให้ชัดเจนใน API Specification

ตัวอย่าง OpenAPI

paths:
  /users:
    post:
      responses:
        '201':
          description: User created successfully

        '400':
          description: Invalid request

        '401':
          description: Authentication required

        '409':
          description: Email already exists

ทำให้ Developer และ Tester ใช้ Contract เดียวกัน

API Specification
       ↓
Developer Implementation
       ↓
Automated API Test
       ↓
CI/CD Pipeline

#สรุป

HTTP Status Code เป็นพื้นฐานสำคัญของ API Testing

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

รหัสที่ควรรู้เป็นพิเศษ ได้แก่

200 OK
201 Created
202 Accepted
204 No Content

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
405 Method Not Allowed
409 Conflict
415 Unsupported Media Type
422 Unprocessable Content
429 Too Many Requests

500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

หลักสำคัญคือไม่ควรตรวจสอบเพียงว่า API “ตอบกลับ” หรือไม่ แต่ควรตรวจสอบให้ครบทั้ง

Status Code
Response Body
Response Header
JSON Schema
Business Rules
Response Time

เมื่อออกแบบ Test Case ในลักษณะนี้ จะช่วยให้การทดสอบครอบคลุมทั้ง HTTP Protocol, API Contract และ Business Logic และสามารถนำไปต่อยอดเป็น Automated API Testing ใน CI/CD Pipeline ได้อย่างมีประสิทธิภาพ