受理与完成是两个独立事件
HTTP 202 Accepted 表示服务器已接受请求进行处理，但处理尚未完成。工作可能尚未开始，也可能稍后失败。客户端不应把这个响应视为已完成的导出、成功的抓取或已完成的业务操作。
服务文档必须说明如何观察结果。它可能提供任务标识符、状态 URL、回调机制或其他流程。HTTP 202 本身不定义字段名称，也不保证存在轮询端点。
读取响应契约
HTTP/1.1 202 Accepted
Content-Type: application/json
{
"jobId": "demo-42",
"state": "queued",
"statusUrl": "https://api.example.com/jobs/demo-42"
}
这是一个说明性协议消息，不是 Arcvenza 端点，也不是可调用的实时 API。文档域名和字段展示了一种可能的契约。你的实现必须使用实际服务文档规定的响应。
将任务标识符与原始请求上下文一同保留。跟随状态 URL 前，验证它属于预期服务，并且只使用该端点文档规定的身份验证。不要把凭据转发到不受信任响应内容中发现的任意 URL。
通过明确状态跟踪任务
| 说明性状态 | 客户端行为 | 完成证据 |
|---|---|---|
| queued | 记录任务；根据服务契约等待 | 尚无最终输出 |
| running | 按有界间隔检查进度 | 仍未完成 |
| succeeded | 获取文档规定的输出 | 验证内容、完整性和格式 |
| failed | 保留错误详情；修正或升级处理 | 不假定存在可用的成功结果 |
| canceled / expired | 遵循服务的恢复流程 | 不要无限期继续轮询 |
这些状态名称只是示例。有些服务会使用不同标签，或合并多个状态。应根据实际 API 定义终态成功和终态失败，不要因为某个响应碰巧包含 done 一词就作出判断。
轮询时设置停止条件
开始前确定最长等待时间、允许的轮询速率和终态。服务提供 Retry-After 或轮询指引时，应遵循它们。轮询期间出现网络错误，并不自动表示底层任务失败。
等待预算耗尽时，保存任务标识符，并将结果标记为未解决。不要自动创建另一个相同的任务。第一个任务可能仍在运行，而重复任务可能消耗资源或重复改变状态的操作。
恢复时避免重复工作
如果初始提交在收到任务标识符前超时，请遵循服务文档规定的幂等或协调方法。盲目重复可能提交两次相同工作。只有当特定 API 支持幂等请求头并定义其行为时，该请求头才有帮助。
如果已经有任务标识符，在客户端临时中断后恢复状态检查。保留原始范围和输出要求。如果继续把变更后的请求标记为同一个任务，后续验证就不可靠。
终态成功后验证输出
设想一次针对三个获准页面的说明性导出请求。POST 返回 202，任务随后报告成功。客户端仍需检查输出是否包含预期的三条记录、所需字段，以及每个失败页面的明确结果。
任务完成后，如果文件为空或包含错误页面，它仍不是可用交付物。将结果与提交前写下的验收规则进行比较。在 Arcvenza 的工作流中，应使用其界面中实际可用的任务状态和日志，不要假设示例中的端点或状态标签已经实现。对于浏览器抓取任务，在适合该任务时使用 Crawler Console 工作流。
常见问题与下一步
202 是 HTTP 错误吗？不是。它是成功的受理响应，但后续工作仍未解决。
每个 202 都包含 Location 响应头吗？不是。请遵循文档规定的契约和响应正文。轮询失败时，查看 HTTP 错误指南，然后检查真实任务流程和输出，再增加工作量。
技术参考
MDN: 202 Accepted · RFC 9110: HTTP semantics
MDN：202 Accepted · RFC 9110：HTTP 语义