HTTP 响应 412 - 您可以包含内容吗？
我正在构建一个 RESTful 数据存储并利用条件 GET 和 PUT。在有条件 PUT 期间，客户端可以包含来自先前对资源的 GET 的 Etag，如果当前表示不匹配，服务器将返回 HTTP 状态代码 412（前提条件失败）。请注意，这是基于 Atom 的服务器/协议。
我的问题是，当我返回 412 状态时，我还可以包含资源的新表示形式还是用户必须发出新的 GET？ HTTP 规范似乎没有规定是或否，Atom 规范也没有规定（尽管他们的示例在响应中显示了一个空实体主体）。不返回新的表示并让客户端专门获取它似乎非常浪费。想法？
I am building a RESTful data store and leveraging Conditional GET and PUT. During a conditional PUT the client can include the Etag from a previous GET on the resource and if the current representation doesn't match the server will return the HTTP status code of 412 (Precondition Failed). Note this is an Atom based server/protocol.
My question is, when I return the 412 status can I also include the new representation of the resource or must the user issue a new GET? The HTTP spec doesn't seem to say yes or no and neither does the Atom spec (although their example shows an empty entity body on the response). It seems pretty wasteful not to return the new representation and make the client specifically GET it. Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
尽管条件 GET 和 PUT 被概括为“条件请求”，但它们在概念上有很大不同。条件 GET 是一种性能优化，条件 PUT 是一种并发控制机制。很难将它们放在一起讨论。
对于有关条件 GET 的问题：如果您发送 GET 并包含 If-None-Match 标头，如果资源已更改，服务器将发送 200 Ok，如果没有更改（如果条件失败），服务器将发送 304 Not Modified。 412 只能与条件 PUT 一起使用。
更新：看来我稍微误读了这个问题。对于您关于失败的条件 PUT 时本地副本“刷新”的观点：很可能缓存已经具有最新版本，并且您的刷新 GET 将从某个缓存提供服务。让服务器使用 412 返回当前实体实际上可能会给您带来更差的性能。
Although conditional GETs and PUTs are summarized as 'conditional requests' they are very different conceptually. Conditional GETs are a performance optimization and conditional PUTs are a concurrency control mechanism. It is hard to discuss them together.
To your question regarding the conditional GET: If you send GET and include an If-None-Match header the server will send 200 Ok if the resource has changed and 304 Not Modified if it did not (if the condition failed). 412 is only to be used with conditional PUTs.
UPDATE: It seems I misread the question slightly. To your point regarding the 'refresh' of the local copy upon a failed conditional PUT: It might well be that a cache already has the newest version and that your refresh-GET will be served from some cache. Having the server return the current entity with the 412 might actually give you worse performance.
不，从技术上讲你不应该。错误代码通常表明出现了问题。尽管没有什么可以阻止您返回内容（事实上，某些错误（例如 404）会返回一个漂亮的页面，表示您没有找到您要查找的内容），但响应的重点不是返回其他内容，而是返回一些信息来告诉您出了什么问题。从技术上讲，您也不应该返回该数据，因为您传递了 If-None-Match: etag （我假设这就是您传递的内容？）
另一方面，您真的需要优化一个额外的 http 调用吗？
我越想这个，就越确信这是一个坏主意 - 您是否会因任何其他错误而返回内容？ PUT 语义是 PUT。 GET 语义应该用于 GET。
No, technically you should not. Error codes are generally to specify that something has gone wrong. Although nothing would stop you from returning content (and in fact, some errors like a 404 return a pretty page that says You didn't find what you're looking for), the point of the response is not to return other content, but to return something that tells you what was wrong. Technically you also should not return that data because you passed the If-None-Match: etag (I'm assuming that's what you passed?)
On another note, do you really need to optimize away one additional http call?
The more I think about this, the more I'm convinced it's a bad idea - Are you going to return the content on any other errors? PUT semantics are to PUT. GET semantics should be used for GET.
如果由于更新冲突后的额外请求而产生的额外请求数量足以让您产生性能问题，那么我建议您可能存在资源粒度问题。
您真的期望多个用户每天数百万次同时编辑同一资源吗？也许您需要存储对资源的增量更改，而不是直接更新资源。如果这些资源确实存在如此多的争用，那么用户就不会不断地处理过时的数据。
如果您的问题是您的资源包含上次修改日期和上次修改用户，并且您必须在每次 PUT 之后执行 GET，那么我会更确信需要扭曲规则。
然而，我认为为了让客户端开发人员清楚，额外请求对性能的影响是值得的。
If the number of additional requests incurred, due to an extra request after an update conflict, is significant enough for you to have performance concerns, then I would suggest you might have issues with the granularity of your resources.
Do you really expect millions of times a day multiple users will be editing the same resource simultaneously? Maybe you need to be storing delta changes to the resource instead updating the resource directly. If there really is that much contention for these resources then aren't users going to be constantly working on out of date data.
If your problem was that your resource contains the last-modified date and last-modified user and you had to do a GET after every PUT then I would be more convinced of the need to twist the rules.
However, I think the performance hit of the extra request is worth it for the clarity to the client developer.