在REST中，我是否应该返回表示以响应PUT？

可以想象，另一个客户也在此期间修改了资源的其他方面。那么，尽管带宽开销，最好的做法是始终在对PUT的响应中包含完整的表示形式？在REST中，我是否应该返回表示以响应PUT？

来源

2010-01-14 Kevin Pauli

返回与交易相关的唯一标识符会更好吗？节省带宽，避免可能不得不返回到服务器，以确保在此期间没有发生任何事情。即如果你返回的数据，它可能无论如何是陈旧的。 – jldupont 2010-01-14 16:29:35

这很奇怪......我在20分钟前问自己那个同样的问题...... – skaffman 2010-01-14 16:31:07

Jldupont的评论指出了我的正确方向。我将使用ETags通过使用If-match头文件as described here执行条件PUT来确定资源是否已被修改。

然后，如果发生冲突，我将让用户决定是从服务器（GET）获取最新表示还是用自己的覆盖更改。

因此，没有必要将响应中的完整表示返回给PUT，只是为了帮助冲突检测和解决。

来源

2010-01-14 16:44:31

我喜欢将GET和DELETE看作一对 - 它们只取一个ID。

POST和PUT看起来也是一对。他们采取序列化的对象，并使其持久。因此，我认为POST和PUT都应该返回创建的结果对象。

在某些情况下，您可能会将额外计算作为持久性的一部分，并且PUT可能会反映这些计算结果。从技术上讲，这可能是第三种正常形式违规，因为你有派生值。但通常，Web服务的全部要点是在POST和可能的PUT中进行一些增值计算。

来源

2010-01-14 16:36:14

我很欣赏你的理念，但不同意（至少部分）。 HTTP规范没有（就像GET一样）要求/禁止/限制DELETE只是一个URL。更重要的是，你不是唯一认为这种情况的人（更重要的是，像Talend这样的主要软件项目是围绕这个假设设计的。）DELETE对单个实体的请求不需要一个主体（如GET），但DELETE对集合的请求是非常激烈的，没有一些数据可以改善请求 – Anthony 2015-09-11 11:51:48

在许多情况下（即使不是大多数情况下），即使服务器通过PUT创建或更新，服务器也会向资源添加内容。示例是时间戳，版本号或从其他人计算出的任何元素。即使您遵循RESTful方法并且不使用PUT进行部分更新，情况也是如此。

仅凭这个原因，返回更新或创建的资源表示通常是PUT请求的一个好主意。但是，我不一定称之为“最佳实践” - 如果您放置一个巨大的2GB图像文件，则可能不希望将其作为响应的一部分返回。另一方面，包括ETag在内，绝对值得“最佳实践”地位。

来源

2010-01-14 18:28:25

您可能希望考虑返回一个303 See Other响应，将Location标头设置为已更新资源的URI（Post/Redirect/Get）。这样客户端即使在临时编辑过程中也收到资源的当前状态（如果它选择遵循Location标题），并且在使用浏览器时不存在重新提交请求的危险。

但是，此模式排除发送对客户端可能有用的适当的成功代码（200 OK,202 Accepted等）。另外，根据你对REST的定义，你可能会认为这是非标准的做法。

如果客户端可能是由人们操作的浏览器，这可能更合适。

来源

2010-11-02 17:42:38

在REST中，我是否应该返回表示以响应PUT？

回答

相关问题