我在某个地方被问过这个问题。
有一个资源，比如说一个 Person 。我们要更新这个人的薪水，假设初始薪水是 10000
PUT - salary = 20000
PUT - salary = 30000
PATCH - Salary = 15000
PATCH - Salary = 0
PUT - salary = 40000
PATCH - salary = 25000
PATCH - salary = 23000
PUT - Salary = 50000
以上所有 REST 调用都是并行执行的。所有 put 和 patch 请求都是并行执行的。
幂等性可以在这里发挥作用。
我将如何确保工资最终应该是50000
以及，如何处理多个休息电话
PUT 和 PATCH 都具有远程创作语义 - “使您的此资源副本看起来与我的副本相同”。您在此处描述的内容类似于点击“保存”八次。如果这些保存同时发生，没有任何控制，那么您可能最终会陷入“最后一位作家获胜”的情况，这可能意味着：
PUT - salary = 20000
PUT - salary = 30000
PATCH - Salary = 15000
PUT - salary = 40000
PATCH - salary = 25000
PATCH - salary = 23000
PUT - Salary = 50000
PATCH - Salary = 0
这大概给你的薪水为 0。
幂等无济于事；如果所有请求都具有 PUT 语义，您将获得相同的“最后写入者获胜”效果。
处理资源并发编辑的一种机制是使用条件请求，请参阅RFC 7232。总之，请求使用前置条件标头和验证器来更具体地说明请求的更改类型“如果您的副本仍然是版本#N，请应用这些编辑”
在这种情况下，共享相同前置条件标头的八个请求的竞争将导致（最多）一个请求被成功应用，其他请求看到412 Precondition Failed。实际上，您将“最后一位作家获胜”替换为“第一位作家获胜”。
也就是说...... HTTP 描述了请求和响应的语义；不是执行。在理解了消息之后，服务器可以做任何它喜欢的事情，并发回适当的响应（例如，发回资源现在的样子，以及适当的标头元数据）。
并发请求的实现是什么样的？当您对一件事应用编辑时，它通常涉及一个锁，它可能是隐式的或显式的。想想数据库中的事务。根据您所做的事情，管理持久存储、域模型或两者中的锁定可能是合适的。