HTTP 202 Accepted: Kiểm tra job, không chỉ phản hồi

Được chấp nhận là một sự kiện riêng với hoàn tất

HTTP 202 Accepted có nghĩa server đã chấp nhận request để xử lý, nhưng quá trình xử lý chưa hoàn tất. Công việc có thể chưa bắt đầu và sau đó vẫn có thể thất bại. Client không nên coi phản hồi này là một lần export đã xong, một lượt crawl thành công hay một tác vụ nghiệp vụ đã hoàn tất.

Tài liệu của service phải giải thích cách quan sát kết quả. Service có thể cung cấp job identifier, status URL, cơ chế callback hoặc workflow khác. Bản thân HTTP 202 không định nghĩa tên field và cũng không bảo đảm có polling endpoint.

Đọc contract của phản hồi

HTTP/1.1 202 Accepted
Content-Type: application/json
 
{
  "jobId": "demo-42",
  "state": "queued",
  "statusUrl": "https://api.example.com/jobs/demo-42"
}

Đây là thông điệp giao thức mang tính minh họa, không phải endpoint Arcvenza hay live API để gọi. Domain tài liệu và các field cho thấy một contract có thể có. Implementation của bạn phải dùng response được tài liệu của service thực tế quy định.

Giữ job identifier cùng với ngữ cảnh request ban đầu. Trước khi truy cập status URL được cung cấp, hãy xác minh URL thuộc service dự kiến và chỉ áp dụng cách xác thực được tài liệu hóa cho endpoint đó. Không chuyển tiếp credentials tới một URL bất kỳ được tìm thấy trong nội dung response không đáng tin cậy.

Theo dõi job qua các trạng thái rõ ràng

Các tên trạng thái này chỉ là ví dụ. Một số service dùng nhãn khác hoặc gộp nhiều trạng thái. Hãy định nghĩa terminal success và terminal failure theo API thực tế thay vì kiểm tra xem một response tình cờ có chứa từ done hay không.

Polling với điều kiện dừng

Xác định thời gian chờ tối đa, tốc độ polling được phép và các trạng thái kết thúc trước khi bắt đầu. Khi có Retry-After hoặc hướng dẫn polling trong tài liệu, hãy tuân theo. Lỗi mạng trong lúc polling không tự động có nghĩa job bên dưới đã thất bại.

Khi hết ngân sách chờ, lưu job identifier và đánh dấu kết quả là chưa xác định. Không tự động tạo một job giống hệt. Job đầu tiên có thể vẫn đang chạy, còn bản sao có thể tiêu tốn tài nguyên hoặc lặp lại thao tác thay đổi trạng thái.

Khôi phục mà không nhân đôi công việc

Nếu lần gửi ban đầu bị timeout trước khi bạn nhận job identifier, hãy theo phương thức idempotency hoặc reconciliation được service tài liệu hóa. Lặp lại mù có thể gửi cùng một công việc hai lần. Idempotency header chỉ hữu ích khi API cụ thể hỗ trợ và định nghĩa cách hoạt động.

Nếu đã có job identifier, hãy tiếp tục kiểm tra trạng thái sau khi client bị gián đoạn tạm thời. Giữ nguyên phạm vi và yêu cầu output ban đầu. Thay đổi request nhưng vẫn gắn nhãn đó là cùng một job sẽ khiến việc xác minh sau này không đáng tin.

Xác minh output sau khi đạt terminal success

Hãy xét một request export minh họa cho ba page được phép. POST trả về 202 và job sau đó báo thành công. Client vẫn cần kiểm tra output có chứa ba record dự kiến, các field mong đợi và kết quả rõ ràng cho mọi page thất bại hay không.

Một job đã hoàn tất nhưng tạo file rỗng hoặc trang lỗi không phải là deliverable có thể sử dụng. So sánh kết quả với tiêu chí nghiệm thu đã viết trước khi submit. Trong workflow của Arcvenza, hãy dùng status task và log thực tế có trong giao diện thay vì giả định endpoint hoặc tên trạng thái trong ví dụ đã được triển khai. Với tác vụ crawl trên trình duyệt, hãy dùng workflow Crawler Console khi phù hợp với công việc.

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

202 có phải lỗi HTTP không? Không. Đây là phản hồi chấp nhận thành công, nhưng công việc phía sau vẫn chưa được giải quyết.

Mọi phản hồi 202 đều có header Location sao? Không. Hãy theo contract và body của response được tài liệu hóa. Xem hướng dẫn lỗi HTTP khi polling thất bại, rồi kiểm tra workflow task và output thực tế trước khi tăng khối lượng.

Tài liệu kỹ thuật

MDN: 202 Accepted · RFC 9110: HTTP semantics

MDN: 202 Accepted · RFC 9110: ngữ nghĩa HTTP