🧠 REST API Client Errors – Hiểu đúng để xử lý lỗi hiệu quả

Khi làm việc với REST API, đôi khi bạn sẽ nhận được những phản hồi không như mong muốn. Những phản hồi này thường đi kèm với mã lỗi HTTP, và việc hiểu rõ chúng sẽ giúp bạn xử lý lỗi một cách thông minh hơn, thay vì loay hoay không biết phải làm gì. ❌ Lỗi không thể khắc phục – Đừng cố retry
Khi gặp những lỗi không thể khắc phục, điều bạn cần làm là dừng việc gửi lại yêu cầu, mà hãy bắt đầu tìm hiểu nguyên nhân lỗi. Cụ thể, cần kiểm tra 3 phần của phản hồi REST API:
Không phải lỗi nào cũng là "dead end". Một số lỗi hoàn toàn có thể xử lý bằng cách thử lại yêu cầu – nhưng cần hiểu rõ bối cảnh và điều kiện. 🧠 Nguyên tắc:
✅ Tóm tắt cho junior:
Nếu bạn đang viết client app hoặc service tích hợp REST API, việc hiểu rõ các mã lỗi này sẽ giúp bạn viết logic xử lý lỗi thông minh và ổn định hơn.
Cứ nhớ: Hiểu lỗi – đọc kỹ phản hồi – sửa đúng cách.
Khi làm việc với REST API, đôi khi bạn sẽ nhận được những phản hồi không như mong muốn. Những phản hồi này thường đi kèm với mã lỗi HTTP, và việc hiểu rõ chúng sẽ giúp bạn xử lý lỗi một cách thông minh hơn, thay vì loay hoay không biết phải làm gì. ❌ Lỗi không thể khắc phục – Đừng cố retry
Khi gặp những lỗi không thể khắc phục, điều bạn cần làm là dừng việc gửi lại yêu cầu, mà hãy bắt đầu tìm hiểu nguyên nhân lỗi. Cụ thể, cần kiểm tra 3 phần của phản hồi REST API:
- Mã trạng thái (Status Code): Đây là con số 3 chữ số mà HTTP server trả về.
- Tiêu đề HTTP (Headers): Có thể chứa thông tin bổ sung như yêu cầu xác thực, thời gian chờ, v.v.
- Nội dung phản hồi (Body): Nhiều API sẽ mô tả rõ lý do lỗi ở đây.
- 401 Unauthorized
→ Lỗi xác thực: Có thể bạn chưa gửi API key, token, hoặc thông tin username/password.
→ Nếu bạn đã từng truy cập thành công, có thể key đã hết hạn hoặc thông tin đăng nhập đã thay đổi. - 403 Forbidden
→ Bạn đã xác thực thành công, nhưng không có quyền truy cập tài nguyên này. Có thể do thiếu role, thiếu permission, hoặc tài nguyên đó bị hạn chế với tài khoản của bạn. - 400 Bad Request
→ Yêu cầu bạn gửi có vấn đề – thường là do cú pháp sai, thiếu tham số, hoặc dùng sai protocol (HTTP thay vì HTTPS).
→ Lúc này, hãy xem kỹ phần body hoặc headers để biết API mong muốn điều gì.
Không phải lỗi nào cũng là "dead end". Một số lỗi hoàn toàn có thể xử lý bằng cách thử lại yêu cầu – nhưng cần hiểu rõ bối cảnh và điều kiện. 🧠 Nguyên tắc:
- Hiểu lý do tại sao lỗi xảy ra
- Xem phần headers/body để biết thông điệp API gửi lại
- Tùy vào mã lỗi, bạn có thể thử lại ngay hoặc chờ một thời gian
- 405 Method Not Allowed
→ Bạn đang dùng sai HTTP method (GET, POST, PUT, DELETE...) để gọi một endpoint.
→ API sẽ trả về tiêu đề Allow liệt kê những method hợp lệ.
Ví dụ:
$ curl -X DELETE -i http://www.google.com/ HTTP/1.1 405 Method Not Allowed Allow: GET, HEAD - 408 Request Timeout
→ Server chờ bạn gửi xong dữ liệu nhưng hết thời gian.
→ Thường xảy ra khi POST tệp lớn mà kết nối mạng chậm.
→ Hãy thử gửi lại nhanh hơn hoặc dùng kết nối ổn định hơn. - 429 Too Many Requests
→ Bạn đã gọi API quá nhiều lần trong thời gian ngắn (rate limit).
→ API thường trả về header Retry-After – bạn phải chờ đúng số giây đó trước khi gửi tiếp. - 411 Length Required
→ Server yêu cầu bạn phải gửi kèm thông tin Content-Length trong header.
→ Thường xảy ra khi bạn gửi một body mà không báo trước độ dài.
✅ Tóm tắt cho junior:
400 | Cú pháp sai | ❌ | Kiểm tra lại request |
401 | Thiếu xác thực | ❌ | Gửi đúng token/API key |
403 | Không có quyền | ❌ | Kiểm tra permission |
405 | Sai method | ✅ | Dùng method trong header Allow |
408 | Hết thời gian | ✅ | Gửi lại nhanh hơn |
411 | Thiếu Content-Length | ✅ | Thêm header này vào |
429 | Gửi quá nhiều request | ✅ | Đợi đúng thời gian Retry-After |
Nếu bạn đang viết client app hoặc service tích hợp REST API, việc hiểu rõ các mã lỗi này sẽ giúp bạn viết logic xử lý lỗi thông minh và ổn định hơn.
Cứ nhớ: Hiểu lỗi – đọc kỹ phản hồi – sửa đúng cách.