我需要对资源进行异步更新。关于202 Accepted是否是对PATCH的适当回应，是否有明确的陈述？
官方文档here，从未提及202，并且似乎假设由于PATCH导致的资源更改是同步进行的，但它从未做出明确的声明。
PATCH操作的适当原理图是什么？
答案 0 :(得分：6)
我不明白为什么返回202是坏事。虽然没有明确提及使用202，但规范在示例中暗示了它。
对现有文本文件的成功PATCH响应：
HTTP / 1.1 204无内容内容 - 位置：/file.txt ETag： “e0023aa4f”
使用204响应代码，因为响应不带有 消息体（具有200代码的响应）。注意
也可以使用其他成功代码。
202是一个成功代码，它的定义并不禁止在PATCH中使用它。
10.2.3 202接受
已接受请求进行处理，但处理已完成 尚未完成。该请求最终可能会或可能不会被采取行动 因为它可能在处理实际发生时被禁止。 没有从异步中重新发送状态代码的工具 这样的操作。
202回复是故意不承诺的。其目的是为了 允许服务器接受某个其他进程的请求（也许是 没有的批处理过程，每天只运行一次 要求用户代理与服务器的连接一直持续到 这个过程完成了。该实体返回此响应 应该包括请求的当前状态和指示 指向状态监视器的指针或用户何时估计 可以期待请求得到满足。
只要您以原子方式进行修补并且异步请求不会使资源处于半修补状态，这应该是好的。