我知道REST PUT操作应该是愿意的。而且我知道它们旨在支持版本管理(因此，如果我尝试更新一个旧版本4的对象，但是新版本为5，我应该得到409冲突响应。但是，处理IDEMTOTENCY的正确方法是什么和版本控制？
假设我的对象有一个版本和一个数据磁场(例如'名称'(。如果我当前的对象位于/对象/1，并且具有名称为" Alice"的版本1，并且我想用Nam'Bob'将其更新为2版，我大概会发送带有版本2和名称'Bob的PUT'。但是，由于它是势力的，所以我应该能够反复发送它，并与单个呼叫相同。随后的调用通常会失败版本控制检查，除了它们的其他数据将与服务器上的数据匹配，并且可以被检测为(或至少假定为(重复请求。
对所有重复呼叫的响应是否相同(例如200可以或204个没有内容(？或者应该指示该呼叫是否实际进行了更改(并增加了版本(，还是被检测到重复调用(否则将标记为409冲突，除了证据中的数据是和已经存在的相同(吗？如果应该指示差异，那么在响应中区分它们的适当方法是什么？
，我想我还应该询问是否通常在对象中进行ret REST版本(例如，使用REST对象的版本字段(，或者是否在REST协议中完成(例如，作为HTTP字段，请保持对象"清洁"(？
对所有重复呼叫的响应是否相同(例如200可以或204个没有内容(？
是 - http规范的相关部分是在RFC 7232中。查看if -Match的描述：
如果接收到的匹配条件评估为false，则原始服务器不得执行请求的方法；相反，原点服务器必须使用a(a(412(前提失败(状态代码或b(2xx(成功(状态代码之一，如果原点服务器已验证了正在请求状态更改并且最终状态已经是反映在目标资源的当前状态中(即用户代理要求的更改已经成功，但是用户代理可能不知道它，也许是因为先前的响应丢失了，或者是其他一些其他一些更改进行的用户代理(。在后一种情况下，原始服务器不得在响应中发送验证器标头字段，除非它可以验证请求是否是同一用户代理进行的立即更改的重复。
我对此的阅读是，服务器不是所需的才能验证更改是否已成功；但是，如果它执行这样的检查，并希望将结果传达给客户，那就是这样做的方法。
我看不出任何理由为什么相同的逻辑不会在您可能使用409冲突状态代码的位置应用。
我想我还应该询问是否通常在对象(例如使用其余对象的版本字段(中进行休息版本，或者是在其余协议中完成的(例如，作为HTTP字段，保留对象＆quot;清洁(？
并非所有媒体类型都使嵌入版本元数据元素在资源的表示中变得方便(我们将相同的图像用于与JSON文档使用的图像(，因此我猜想看到版本化信息更典型在元数据(也就是说，在RFC 7232所述的标题中(。
如果应该指示差异，则在响应中区分它们的适当方法是什么？
未指定；您可以在那里做有意义的事情。在"成功"的情况下，您应该发送"诉讼状态"的"代表"以及2XX类状态代码(请参阅RFC 7231 6.3.1(。使用409 Conflict/412 Precondition Failed-由于这些状态代码是4xx类的成员，您应该发送"包含错误情况的说明的表示形式，以及它是临时还是永久条件(请参阅RFC 7231 6.5(。
在RFC 7807中查看http API的问题细节中的示例可能很有帮助。