如何以幂等方式重命名资源？

Question

我实施了重命名公司如下的API：

PUT /companies/A 
{ 
    "name": "B" 
} 

将返回HTTP 301与Location头在该公司的新的URI指出：/companies/B。

我该如何使这个操作幂等与If-Match标题？

1. 没有If-Match头：如果用户试图重命名一个不存在的公司，我期望服务器返回HTTP 404，但我不能这样做，因为当时合法的重命名操作不会幂（他们会在第一次返回301，在后续调用时返回404）。这是有问题的，因为我希望客户能够区分失败的重命名（公司不存在）和已经发生的重命名。

2. With If-Match标题：如果公司的ETag取决于公司名称，则后续重命名操作将失败，因为前提条件不再成立。再一次，这使得看起来操作失败了，事实上它已经发生了。

Answer 1

放置操作成功，应返回相同的资源200或201的后续请求应该返回一个301指示新资源的URI的适当响应主体。

404只应用于真正无法找到的资源，即不存在且永不存在的公司。

如protocol所述，幂等性并不意味着该调用始终返回相同的结果。这意味着没有副作用。此外，幂等性不适用于错误条件下，除2xx之外的任何其他（如301）。

我真的很佩服我们承诺按规范正确使用它的承诺，但是与所有的事情一样，它是受制于解释的。

Answer 2

我不认为3xx在这里有意义。 PUT操作成功，所以它应该返回一个2xx。 301意味着资源不在请求者认为的地方。

一般来说，我一直觉得挺有趣关于人不使用MOVE当他们真正想要MOVE :-)

Answer 3

好的，这已经两岁了，但我会回答它，以防其他人像我一样绊倒它。

简短的回答是，从HTTP点，重命名（移动）资源不幂，你应该使用POST代替PUT。

长的答案：PUT是“创建或 - 替换”操作，通过RFC 2616定义如下（重点煤矿）：

将所附实体下提供的存储的PUT方法请求Request-URI。

RFC 7231（这在这个问题被问时存在只是作为草案），提出更加明确：

目标资源的状态是 创建或取代他们的是PUT方法请求包含在请求消息有效载荷中的表示 定义的状态。一个给定的 表示的成功PUT将表明对相同 目标资源的后续GET将导致等效表示是 在200（OK）响应发送。

因为一个成功的重命名将导致资源在不同位置可用，PUT是不适用的。

PS。也许你可以在PUT上做这项工作，方法是在请求正文中包含公司的某种唯一标识符，而不管它的名称或其他属性如何，这将允许您检测先前的重命名并发出适当的重定向。不过，我认为这是违背协议，POST会更合适。