摘要

  • 202 Accepted 表示请求已获受理，但处理尚未完成。
  • 该操作仍可能被拒绝、取消或过期，也可能因授权失效而停止，甚至在结束后仍未产生预期副作用。
  • 任何依赖“已完成”这一事实的决策，都需要一份异步操作凭证，把原始请求、作为正式记录的状态监视器和终态结果连接起来。

设想一个变更控制器提交访问策略轮换请求。服务返回 202 Accepted，并附上操作链接。控制器随即把变更标为完成，撤销旧凭证，并删除输入材料。几分钟后，排队中的操作才到达工作进程；工作进程重新检查策略后拒绝执行。请求确实被受理了，但变更从未发生。

错误不在状态码，而在于把分布式操作中的一个阶段提升为后续所有阶段的证明。

RFC 9110 对 202 Accepted 的定义十分克制：服务器已接受请求进行处理，但处理尚未完成。请求日后可能得到执行，也可能在实际处理时被判定为不允许。这个响应有意不对最终结果作出承诺。

这一边界之所以重要，是因为 HTTP 响应交换已经结束。RFC 9110 指出，HTTP 没有办法在已经完成的响应交换中，稍后再次发送异步操作的状态码。客户端若把最初的 202 当作终态成功，就凭空补上了协议从未交付的后续事实。

响应表示应当说明请求当前的状态，并指向或嵌入状态监视器。这项建议很有价值，但一条 URL 本身并不是完成凭证。监视器必须是同一个操作的正式记录，能够在预期的安全上下文中访问，保存时间足以支持相关决策，并明确区分各种终态。通用队列页面、目标会变化的“最新任务”端点，或最终返回 404 的链接，都不足以承载完整证据。

RFC 7240 提供了一个相关但不同的信号。客户端可以发送 Prefer: respond-async，表达希望异步处理；服务器可以用 202 表示接受这一偏好。偏好选择的是交互方式，而不是证明延后的工作已经执行。如何确定最终结果，规范留给具体实现处理。

Preference-Applied 的含义同样有限。按照 RFC 7240，它可以说明服务器采纳了哪些请求偏好，因此能够确认服务器选择了异步方式。它不能确认工作进程已经启动，也不能确认写入、通知、部署或任何其他后续副作用已经发生。

一份可靠的操作记录至少要分开保存三类事实。第一类是受理：在何处观察到哪些请求字节、请求方身份、目标、幂等键和响应。第二类是执行：哪个操作标识进入了哪条队列、由哪个工作进程领取、当时重新验证了哪些授权与依赖，以及取消或过期是否介入。第三类是结果：哪些副作用已经提交、返回了什么终态，以及该终态现在是否仍是正式记录。

这些连接很容易丢失。网关可能生成 202，队列却由另一项服务控制；操作链接可能指向租户相对的任务，在另一组凭证下含义不同；重试可能命中同一任务，也可能在缺少幂等控制时创建第二个任务；工作进程启动时，请求方可能已经失去权限；下游效果尚不可观察时，系统也可能先写入“成功”。

这些情况并不说明 202 有缺陷。异步受理的价值，正是让连接不必为长时间运行的流程一直保持开放。正确做法是把响应保存为受理证据，并为后续每一项主张取得对应的后续证据。

真正有用的证据对象是一份异步操作凭证。它把请求方法、目标和正文摘要，与经过认证的请求方、当时有效的授权状态、幂等键、观察点、202 响应、操作标识以及正式状态监视器的 URI 绑定；随后再记录入队、工作进程领取、最新授权与依赖检查、取消状态、副作用标识、终态结果、观察时间，以及使用这一结果作出的决策。

来源

RFC 9110 — HTTP Semantics, 202 Accepted；RFC 7240 — Prefer Header for HTTP。