Một lỗi rất hay gặp khi làm dự án:
User nói:
“Em không chuyển tiền được.”
“Em không đăng nhập được.”
“Em bấm thanh toán nhưng lỗi.”
Nếu BA chỉ hỏi:
“Lỗi gì vậy anh/chị?”
Thường sẽ nhận lại câu:
“Không biết, nó báo lỗi thôi.”
Nhưng nếu BA hiểu HTTP Status Code, bạn sẽ biết cách hỏi sâu hơn:
Có phải request gửi sai không?
User đã đăng nhập chưa?
User có quyền thực hiện thao tác không?
API không tìm thấy dữ liệu?
Hay server đang lỗi?
=> Đây là lý do BA không cần code API, nhưng nên hiểu các status code cơ bản.
HTTP Status Code là gì?
Hiểu đơn giản:
HTTP Status Code = mã phản hồi cho biết API xử lý request như thế nào.
Khi app gọi API:
App gửi request
=> Server xử lý
=> Server trả response
=> Response thường có status code
Status code giúp team biết:
Thành công hay thất bại
Lỗi do user/request
Lỗi do quyền truy cập
Lỗi do data không tồn tại
Lỗi do server
✅ 200 - Thành công
Ý nghĩa:
Request hợp lệ.
Server xử lý thành công.
Có thể trả data về cho app.
Ví dụ:
User xem danh sách đơn hàng
=> API trả 200 OK
=> App hiển thị danh sách đơn
{
"status": "SUCCESS",
"data": [
{
"orderId": "ORD001",
"status": "DELIVERED"
}
]
}
BA cần hỏi:
Thành công thì UI hiển thị gì?
Data nào cần trả về?
Có cần message thành công không?
Status business là gì? SUCCESS, PENDING, hay COMPLETED?
Lưu ý quan trọng:
HTTP 200 không phải lúc nào cũng đồng nghĩa business thành công.
Ví dụ API trả 200 nhưng bên trong response là:
{
"status": "FAILED",
"errorCode": "INSUFFICIENT_BALANCE"
}
=> Về mặt kỹ thuật API gọi được.
=> Nhưng về mặt business, giao dịch thất bại.
Đây là chỗ BA phải phân biệt rõ.
2️⃣ 400 - Request sai
Ý nghĩa:
App gửi request không hợp lệ.
Ví dụ:
User chuyển tiền nhưng nhập số tiền âm:
{
"amount": -50000
}
Server có thể trả 400 Bad Request.
BA cần hỏi:
Field nào bắt buộc?
Format dữ liệu đúng là gì?
Amount tối thiểu/tối đa là bao nhiêu?
Nếu user nhập sai, message hiển thị là gì?
Validate ở FE, BE hay cả hai?
Ví dụ exception flow:
User nhập số tiền nhỏ hơn 0
=> App gửi request
=> API trả 400
=> UI hiển thị: “Số tiền chuyển phải lớn hơn 0”
3️⃣ 401 - Chưa xác thực
Ý nghĩa:
User chưa đăng nhập, session hết hạn, hoặc token không hợp lệ.
Ví dụ:
User mở app quá lâu, token hết hạn.
Sau đó bấm “Chuyển tiền”.
API trả 401 Unauthorized.
BA cần hỏi:
Khi session hết hạn thì app xử lý thế nào?
Có redirect về màn login không?
Có lưu lại thao tác user đang làm không?
Message hiển thị là gì?
Ví dụ exception flow:
User token hết hạn
=> Gọi API chuyển tiền
=> API trả 401
=> App hiển thị: “Phiên đăng nhập đã hết hạn. Vui lòng đăng nhập lại.”
4️⃣ 403 - Không có quyền
Ý nghĩa:
User đã đăng nhập rồi, nhưng không được phép thực hiện hành động đó.
Khác với 401:
401 = chưa xác thực / chưa đăng nhập hợp lệ
403 = đã xác thực nhưng không có quyền
Ví dụ:
Nhân viên CSKH đăng nhập hệ thống admin.
Họ được xem đơn hàng nhưng không được hoàn tiền.
Khi bấm “Refund”, API trả 403 Forbidden.
BA cần hỏi:
Role nào được quyền dùng tính năng?
Role nào chỉ được xem?
Role nào được tạo/sửa/xóa/duyệt?
Nếu không có quyền, ẩn button hay cho bấm rồi báo lỗi?
Có cần audit log khi user cố thao tác không?
Ví dụ exception flow:
User không có quyền refund
=> API trả 403
=> UI hiển thị: “Bạn không có quyền thực hiện thao tác này.”
5️⃣ 404 - Không tìm thấy
Ý nghĩa:
Resource không tồn tại hoặc không tìm thấy.
Ví dụ:
User mở link chi tiết đơn hàng ORD999
Nhưng đơn hàng này đã bị xóa, sai mã, hoặc không thuộc user đó.
API trả 404 Not Found.
BA cần hỏi:
Khi không tìm thấy data thì hiển thị gì?
Có quay về danh sách không?
Có phân biệt “không tồn tại” và “không có quyền xem” không?
Có cần log lại không?
Ví dụ exception flow:
User mở đơn hàng không tồn tại
=> API trả 404
=> UI hiển thị: “Không tìm thấy đơn hàng.”
6️⃣ 500 - Lỗi server
Ý nghĩa:
Request có thể đúng, user có thể hợp lệ, nhưng server xử lý lỗi.
Ví dụ:
User bấm “Thanh toán”
=> API payment bị lỗi nội bộ
=> Server trả 500 Internal Server Error
BA cần hỏi:
UI hiển thị message gì?
Có cho user retry không?
Có tạo transaction pending không?
Có ghi log để support kiểm tra không?
Có gửi alert cho team vận hành không?
Ví dụ exception flow:
Payment API trả 500
=> App không hiển thị “thanh toán thành công”
=> UI hiển thị: “Hệ thống đang gián đoạn. Vui lòng thử lại sau.”
=> System ghi log lỗi để support kiểm tra
Mini case: User báo “không chuyển tiền được”
Nếu BA không hiểu status code, bạn sẽ hỏi rất chung:
“Anh/chị thao tác như thế nào?”
Nhưng nếu hiểu status code, bạn sẽ hỏi sắc hơn:
Nếu là 400:
User nhập số tiền bao nhiêu?
Số tài khoản có đúng format không?
Request thiếu field nào không?
Nếu là 401:
User có bị hết phiên đăng nhập không?
Có cần login lại không?
Nếu là 403:
User có quyền chuyển tiền không?
Tài khoản có bị giới hạn giao dịch không?
Nếu là 404:
Tài khoản nhận có tồn tại không?
Beneficiary ID có còn hợp lệ không?
Nếu là 500:
Lỗi xảy ra từ server hay hệ thống đối tác?
Có cần retry hoặc chuyển trạng thái pending không?
=> Cùng một câu “không chuyển tiền được”, nhưng status code giúp BA xác định đúng hướng điều tra.
Cách BA dùng status code để viết exception flow
Khi viết requirement API, đừng chỉ viết success case.
Hãy thêm phần exception flow như sau:
Success:
API trả 200
UI hiển thị kết quả thành công
System cập nhật trạng thái giao dịch
Exception:
400: Hiển thị lỗi input cụ thể
401: Yêu cầu đăng nhập lại
403: Thông báo không có quyền
404: Thông báo không tìm thấy dữ liệu
500: Thông báo lỗi hệ thống, cho phép thử lại sau
Cho người mới bắt đầu thì đây nha ae, học lý thuyết + hướng dẫn áp dụng thực hành dự án để ghi vào CV (Quà tặng hơn 30 khóa ở đây):
=> https://www.facebook.com/groups/3514587515337829/posts/3618897148240198/
Đã có kiến thức BA cơ bản thì học các Khóa học chuyên sâu về các domain cùng case study thực tế: Bảo hiểm - ERP - Banking - E-commerce - Chính Phủ (GOV) - Logistis, tìm hiểu tại đây:
https://www.facebook.com/groups/3514587515337829/posts/3714548542008391
