0

Mã trạng thái HTTP (HTTP Status Code): Ý nghĩa, 5 Nhóm mã chính & Tiêu chuẩn thiết kế RESTful API

Khi bạn truy cập một trang web hoặc gửi một yêu cầu (request) qua API, máy chủ (server) sẽ luôn trả về một thông điệp để báo cho máy khách (client / trình duyệt) biết tình trạng của yêu cầu đó. Thông điệp này được gọi là Mã trạng thái HTTP (HTTP Status Code).

Đoạn code bạn thường thấy trong các framework lớn (như Laravel hay Symfony) với các hằng số như HTTP_OK = 200 hay HTTP_NOT_FOUND = 404 chính là cách các lập trình viên chuẩn hóa ngôn ngữ giao tiếp này. Việc sử dụng hằng số giúp code dễ đọc, dễ bảo trì và tránh việc sử dụng "magic numbers" (những con số vô hồn không rõ ý nghĩa).

Dựa vào chữ số đầu tiên, các mã trạng thái HTTP được chia thành 5 nhóm chính. Hãy cùng giải mã chúng:


1. Nhóm 1xx: Informational (Thông tin)

Nhóm này mang tính chất thông báo tạm thời, cho biết máy chủ đã nhận được yêu cầu và đang trong quá trình xử lý. Trình duyệt hoặc client thường tự động xử lý các mã này ở chế độ nền.

  • 100 Continue: Máy chủ đã nhận được phần đầu của yêu cầu, client có thể tiếp tục gửi phần còn lại.
  • 101 Switching Protocols: Máy chủ đồng ý chuyển đổi giao thức theo yêu cầu của client (ví dụ: chuyển từ HTTP sang WebSocket).

2. Nhóm 2xx: Success (Thành công)

Đây là nhóm mã mà bất kỳ lập trình viên nào cũng muốn nhìn thấy. Nó báo hiệu yêu cầu đã được máy chủ tiếp nhận, hiểu và xử lý thành công.

  • 200 OK: Quen thuộc nhất! Yêu cầu đã thành công (Ví dụ: tải xong một trang web hoặc lấy dữ liệu API thành công).
  • 201 Created: Yêu cầu thành công và một tài nguyên mới đã được tạo ra (thường gặp khi gửi yêu cầu POST để thêm dữ liệu mới).
  • 204 No Content: Xử lý thành công nhưng không có dữ liệu nào được trả về (thường dùng cho yêu cầu DELETE hoặc PUT).

3. Nhóm 3xx: Redirection (Chuyển hướng)

Khi nhận được mã 3xx, client cần thực hiện thêm một bước nữa (thường là truy cập vào một URL khác) để hoàn tất yêu cầu.

  • 301 Moved Permanently: Tài nguyên đã được chuyển vĩnh viễn sang một URL mới. Rất quan trọng cho SEO khi bạn đổi đường dẫn bài viết.
  • 302 Found / 307 Temporary Redirect: Chuyển hướng tạm thời. URL cũ vẫn còn giá trị trong tương lai.
  • 304 Not Modified: Dữ liệu không thay đổi kể từ lần cuối client tải về. Client có thể dùng lại bản lưu trong cache, giúp tăng tốc độ tải trang.

4. Nhóm 4xx: Client Errors (Lỗi từ phía người dùng/máy khách)

Lỗi xảy ra do người dùng hoặc ứng dụng client gửi yêu cầu sai, thiếu quyền hoặc tìm kiếm thứ không tồn tại.

  • 400 Bad Request: Cú pháp yêu cầu không hợp lệ (ví dụ: gửi sai định dạng JSON).
  • 401 Unauthorized: Bạn chưa xác thực (chưa đăng nhập hoặc token hết hạn).
  • 403 Forbidden: Bạn đã xác thực nhưng không có quyền truy cập vào tài nguyên này.
  • 404 Not Found: Quá nổi tiếng! Máy chủ không tìm thấy tài nguyên bạn yêu cầu (sai URL hoặc bài viết đã bị xóa).
  • 405 Method Not Allowed: Phương thức HTTP không được hỗ trợ (ví dụ: API chỉ nhận POST nhưng bạn lại gửi GET).
  • 422 Unprocessable Entity: Dữ liệu gửi lên đúng định dạng nhưng không qua được bước kiểm tra tính hợp lệ (Validation fails).
  • 429 Too Many Requests: Bạn đang "spam" máy chủ. Bị chặn do gửi quá nhiều yêu cầu trong một thời gian ngắn (Rate limiting).
  • 418 I'm a teapot: Một mã lỗi khá hài hước ("Tôi là một ấm trà"). Đây là một trò đùa Cá tháng Tư (RFC 2324) của giới công nghệ từ năm 1998, báo rằng máy chủ từ chối pha cà phê vì nó là một... ấm trà.

5. Nhóm 5xx: Server Errors (Lỗi từ phía máy chủ)

Client gửi yêu cầu đúng, nhưng máy chủ gặp sự cố và không thể xử lý được. Đây là lúc các backend developer phải "đau đầu" kiểm tra lại hệ thống.

  • 500 Internal Server Error: Lỗi chung chung từ phía server (ví dụ: lỗi cú pháp trong code backend, lỗi kết nối database).
  • 502 Bad Gateway: Máy chủ hoạt động như một cổng trung gian (proxy) và nhận được phản hồi không hợp lệ từ máy chủ gốc.
  • 503 Service Unavailable: Máy chủ hiện không thể xử lý yêu cầu (do đang bảo trì hoặc bị quá tải).
  • 504 Gateway Timeout: Cổng trung gian không nhận được phản hồi từ máy chủ gốc trong thời gian cho phép.

💡 Lời Kết

Việc hiểu và sử dụng chính xác các mã trạng thái HTTP không chỉ giúp ứng dụng của bạn hoạt động mượt mà, dễ debug (sửa lỗi) mà còn thể hiện sự chuyên nghiệp khi thiết kế RESTful API. Thay vì luôn trả về 200 OK kèm theo một tin báo lỗi bên trong nội dung, hãy để các mã trạng thái HTTP thực hiện đúng sứ mệnh của nó!


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí