HTTP status code là gì?

HTTP status code (mã trạng thái HTTP) là con số ba chữ số mà server trả về trong mỗi HTTP response để cho client biết request vừa rồi được xử lý ra sao. Chữ số đầu tiên chia thành 5 nhóm: 1xx thông tin, 2xx thành công, 3xx chuyển hướng, 4xx lỗi do client gửi sai, 5xx lỗi do server.

Với tester, đọc đúng http status code chính là bước đầu để biết bug nằm ở đâu. Một mã http 4xx nói "request của bạn có vấn đề"; một mã 5xx nói "server tôi đang hỏng". Hai câu chuyện hoàn toàn khác nhau, dẫn tới hai cách báo bug khác nhau. Nếu bạn còn mơ hồ về API và request–response, hãy đọc trước API RESTful là gì để nắm nền tảng, rồi quay lại bảng tra bên dưới.

5 nhóm status code (1xx–5xx) — bảng tổng quan

Mọi http status code đều bắt đầu bằng một chữ số xác định nhóm. Trước khi đi vào từng mã, hãy nhớ logic của chữ số đầu — nắm được nhóm thì bạn đoán được "ai có lỗi" mà chưa cần thuộc lòng từng số:

Nhóm Tên Ý nghĩa ngắn gọn Ai chịu trách nhiệm
1xx Informational Server đã nhận request, đang xử lý tiếp (hiếm gặp khi test thủ công)
2xx Success Request thành công Mọi thứ ổn
3xx Redirection Cần thao tác thêm (thường là chuyển hướng) Client đi theo hướng mới
4xx Client Error Request sai (sai cú pháp, thiếu quyền, sai địa chỉ) Client / phía gửi request
5xx Server Error Server gặp sự cố khi xử lý Server / phía backend

Nhóm 3xx như 301 (Moved Permanently) và 302 (Found) chủ yếu liên quan chuyển hướng URL; tester web cần để mắt khi kiểm tra redirect, nhưng trong test API REST thuần thì 2xx, 4xx và 5xx mới là ba nhóm bạn gặp hằng ngày. Vì vậy phần dưới tôi đào sâu ba nhóm này.

2xx Thành công (200/201/204)

Nhóm 2xx báo request đã thành công, nhưng "thành công" có nhiều sắc thái:

Mã Tên Khi nào trả về Tester nên test gì
200 OK GET/PUT thành công, có dữ liệu trả về Kiểm tra cả body, không chỉ mã: đúng field, đúng giá trị, đúng kiểu
201 Created POST tạo mới thành công Tài nguyên đã thực sự được tạo? GET lại để xác nhận; kiểm tra header Location
204 No Content Thành công nhưng không có body (thường là DELETE) Body rỗng đúng kỳ vọng; gọi GET lại để chắc dữ liệu đã bị xóa

Cái bẫy lớn nhất ở nhóm này: 200 không có nghĩa là "đúng". Trong hệ thống đặt phòng họp nội bộ tôi hay lấy làm ví dụ, API có thể trả 200 OK nhưng body lại báo "error": "Phòng đã được đặt". Status nói thành công, nội dung lại là lỗi nghiệp vụ. Nếu test case của bạn chỉ assert status == 200 mà quên đọc body, bug lọt lưới ngon ơ. Đây là lỗi tôi sửa cho học viên nhiều nhất.

4xx Lỗi client (400/401/403/404/422)

Nhóm 4xx nói: "request của bạn có vấn đề". Đây là nhóm tester chạm nhiều nhất khi viết negative test:

Mã Tên Khi nào trả về Tester nên test gì
400 Bad Request Request sai cú pháp / JSON hỏng / thiếu trường bắt buộc Gửi body sai định dạng, thiếu field; xem API có chặn đúng không
401 Unauthorized Chưa xác thực — thiếu hoặc sai token Gọi API không kèm token, token hết hạn, token sai
403 Forbidden Đã xác thực nhưng không đủ quyền Đăng nhập tài khoản thường rồi gọi API admin
404 Not Found Không tìm thấy tài nguyên ở địa chỉ đó Gọi ID không tồn tại, sai endpoint
422 Unprocessable Entity Cú pháp đúng nhưng vi phạm quy tắc nghiệp vụ Ngày kết thúc < ngày bắt đầu, email sai định dạng

Hai cặp dễ nhầm nhất:

  • 401 vs 403. 401 là "tôi không biết bạn là ai" (chưa đăng nhập / token sai). 403 là "tôi biết bạn là ai rồi, nhưng bạn không được phép làm việc này". Mẹo nhớ: 401 thiếu danh tính, 403 thiếu quyền.
  • 400 vs 422. 400 là sai cú pháp (JSON gãy, thiếu field). 422 là cú pháp đúng nhưng dữ liệu phạm luật nghiệp vụ — ví dụ đặt phòng với giờ kết thúc trước giờ bắt đầu. Nhiều API gộp cả hai vào 400; khi viết test, bạn cứ kiểm tra API trả mã nào và mã đó có nhất quán không.

5xx Lỗi server (500/502/503)

Nhóm 5xx nói: "request của bạn có thể đúng, nhưng server tôi đang trục trặc". Đây là tín hiệu bug phía backend, cần báo cho dev:

Mã Tên Khi nào trả về Tester nên test gì
500 Internal Server Error Lỗi chung chung trong code server Xem có input nào khiến server "vỡ" thành 500 thay vì trả 4xx rõ ràng
502 Bad Gateway Server trung gian nhận response lỗi từ server upstream Thường gặp khi backend/microservice phía sau chết
503 Service Unavailable Server tạm quá tải hoặc đang bảo trì Kiểm tra hành vi khi tải cao; có retry / thông báo rõ không

Một nguyên tắc tôi luôn nhắc: lỗi do người dùng nhập sai phải trả 4xx, không phải 5xx. Nếu bạn gửi một body thiếu trường bắt buộc mà API trả về 500, đó chính là một bug đáng báo — server lẽ ra phải bắt lỗi đầu vào và trả 400 gọn gàng, chứ không nên "vỡ" thành lỗi 500 chung chung. Khi gặp 5xx, hãy ghi lại đầy đủ request đã gửi để dev tái hiện; cách ghi bug chuẩn xem thêm ở vòng đời của bug.

Status code tester hay nhầm/test sai

Sau nhiều khóa, tôi thấy lỗi đọc http status code lặp lại theo vài kiểu rất quen:

  • Chỉ assert status, quên kiểm tra body. 200 OK nhưng dữ liệu sai vẫn là bug. Test API tốt phải kiểm tra cả mã lẫn nội dung response.
  • Nhầm 401 với 403. Báo "lỗi phân quyền" trong khi thực ra là chưa đăng nhập, khiến dev điều tra sai hướng.
  • Coi 5xx và 4xx như nhau. Hai nhóm này chỉ về hai người khác nhau: 4xx là phía gửi request, 5xx là phía server. Phân biệt đúng giúp bug đi đúng địa chỉ.
  • Bỏ qua negative test. Chỉ test "đường hạnh phúc" (200/201) mà không thử các ca lỗi 400/401/403/404 — trong khi đây mới là chỗ API hay vỡ.
  • Mặc định 404 luôn là bug. 404 đôi khi là hành vi đúng (gọi tài nguyên không tồn tại thì phải trả 404). Hãy đối chiếu với kỳ vọng, đừng vội kết luận.

Muốn luyện phản xạ đọc status code, bạn nên thực hành gửi request thật với Postman test API — gửi cả ca hợp lệ lẫn ca lỗi rồi quan sát mã trả về.

Bảng tra nhanh cho tester

Đây là cheat sheet http status code để bạn dán cạnh màn hình. Mỗi dòng là một http response code hay gặp kèm "nên làm gì khi thấy nó":

Mã Nhóm Nghĩa nhanh Phản xạ của tester
200 2xx OK Đọc body, đừng tin mỗi mã
201 2xx Đã tạo mới GET lại xác nhận, check Location
204 2xx Thành công, không body Đảm bảo body rỗng đúng kỳ vọng
301 / 302 3xx Chuyển hướng Kiểm tra URL đích đúng không
400 4xx Request sai cú pháp Đúng kỳ vọng cho input hỏng?
401 4xx Chưa xác thực Token thiếu/sai/hết hạn
403 4xx Không đủ quyền Test phân quyền theo vai trò
404 4xx Không tìm thấy Đối chiếu kỳ vọng, chưa chắc là bug
422 4xx Sai luật nghiệp vụ Test validation đầu vào
500 5xx Lỗi server chung Báo bug, đính kèm request
502 / 503 5xx Gateway lỗi / quá tải Test hành vi khi backend trục trặc

Bảng này là phần lõi tôi cho học viên thực hành trong khóa API Testing: nhìn mã là biết phải kiểm tra gì tiếp theo. Để hiểu mã trạng thái nằm ở đâu trong bức tranh kiểm thử dịch vụ, đọc thêm API testing là gì.