Dùng mã lỗi HTTP để chọn bước chẩn đoán tiếp theo

Mã phản hồi là bằng chứng, không phải toàn bộ sự cố

Mã lỗi HTTP mô tả kết quả của một request cụ thể. Phản hồi 4xx hướng tới vấn đề về request hoặc quyền truy cập; phản hồi 5xx cho biết lỗi phía server khi xử lý request đó. Mã chính xác, header, body phản hồi và ngữ cảnh request quyết định hành động tiếp theo hữu ích.

Trước hết, hãy tách phản hồi HTTP khỏi lỗi DNS, kết nối hoặc TLS. Nếu client chưa bao giờ nhận được HTTP status, bảng mã HTTP không thể giải thích toàn bộ vấn đề. Giữ lại thông báo lỗi và xử lý đúng lớp đã thất bại.

Thu thập phản hồi nhỏ, dễ kiểm tra

curl --silent --show-error --max-time 20 --dump-header response-headers.txt --output response-body.html https://example.com/

Ví dụ công khai này lưu header và body riêng biệt. Hãy dùng target được phép và kiểm tra các file thay vì coi body không rỗng là thành công. Trên Windows, dùng curl.exe khi cần để tránh alias của shell.

Với API yêu cầu xác thực, hãy che credentials, cookie, token, dữ liệu cá nhân và tham số query nhạy cảm trước khi chia sẻ trace. Giữ lại method, đường dẫn endpoint, timestamp và một correlation identifier an toàn. Tuyệt đối không dán toàn bộ Authorization header vào bài đăng hỗ trợ công khai.

Đối chiếu mã phổ biến với một kiểm tra cụ thể

Mã status có thể do một intermediary tạo ra thay vì ứng dụng mà bạn định truy cập. Đọc header và body phản hồi để hiểu ngữ cảnh. Tránh suy ra nguồn gốc chính xác của lỗi chỉ từ một trang lỗi mang thương hiệu.

Đừng retry mọi lỗi theo cùng một cách

Sửa request sai định dạng trước khi gửi lại. Khôi phục authorization hợp lệ theo quy trình trong tài liệu thay vì xoay vòng identity hoặc route. Với rate limit, giảm tốc độ request và tuân theo hướng dẫn delay của provider thay vì tìm cách vượt giới hạn.

Retry có thể nhân đôi một thao tác thay đổi trạng thái nếu lần đầu đã thành công nhưng phản hồi bị mất. Kiểm tra bảo đảm idempotency của API và các key được hỗ trợ trước khi retry POST. Chỉ dùng số lần thử và backoff có giới hạn khi retry phù hợp.

Phân biệt công việc được chấp nhận với công việc đã hoàn tất

Không phải mọi phản hồi 2xx đều có nghĩa tác vụ nghiệp vụ đã xong. HTTP 202 cho biết request được chấp nhận để xử lý, trong khi job sau đó vẫn có thể thất bại. Hãy theo resource job hoặc status được tài liệu mô tả thay vì ngay lập tức lấy output chưa tồn tại.

Hướng dẫn HTTP 202 có walkthrough riêng cho trạng thái job. Hãy tách success ở lớp HTTP, job hoàn tất và output có thể sử dụng thành các bước kiểm tra khác nhau. Sự tách biệt này đặc biệt quan trọng trong workflow crawl và xử lý dữ liệu.

Xử lý bằng một thay đổi có kiểm soát

Hãy hình dung một API request được phép trả về 415 vì client gửi body JSON nhưng không dùng media type được tài liệu mô tả. Lưu response, so sánh request với contract API hiện tại, sửa cặp header và body, rồi gửi lại một request có giới hạn.

Nếu request được chấp nhận, hãy kiểm tra response thực tế và mọi trạng thái task trước khi mở rộng workload. Ghi lại field đã thay đổi và kết quả. Một ghi chú sự cố rõ ràng cho thấy vấn đề nằm ở đâu, đã thay đổi gì và tác vụ ban đầu được xác minh ra sao.

Câu hỏi thường gặp và bước tiếp theo

Một phản hồi 200 có thể chứa sai trang không? Có. Ứng dụng có thể trả về màn hình hoặc nội dung không mong muốn cùng HTTP status thành công. Hãy xác minh các field và body bắt buộc.

Tôi nên tiếp tục từ đâu? Dùng hướng dẫn curl POST hiện có để thiết lập request body hoặc hướng dẫn download để xác minh file. Chỉ dùng workflow được Arcvenza tài liệu hóa cho các thao tác được hỗ trợ và target được phép.

Tài liệu kỹ thuật

MDN: HTTP response status codes · RFC 9110: HTTP semantics · curl command manual

MDN: mã status phản hồi HTTP · RFC 9110: ngữ nghĩa HTTP · curl command manual