问Web恢复和Accept-Datetime报头

EN

因此，RFC 7089中描述的机制定义了对HTTP1.1规范中定义的内容协商机制的扩展。今天官方支持的内容协商参数是：

• 接受
• 接受字符集
• 接受语言
• 用户代理

这些标头用于通知服务器对特定版本的资源的需求(例如，Accept-Language: de)。HTTP1.1规范定义了服务器在试图请求它不支持的内容类型时可以做什么。在这种情况下，服务器应该用406 (不可接受的)响应来响应。根据规范，406项答复表明：

The resource identified by the request is only capable of generating
response entities which have content characteristics not acceptable
according to the accept headers sent in the request.

这与用户指定他们想要资源的特定实时版本是一致的，但是该版本并不存在。

所以，对于你的第一个问题(在初始日期之前询问日期)，你应该用406回答。

对于第二个问题(如何处理非版本化的资源)，您可以在请求的时候选择资源状态的含义。

如果您认为非版本化的信息没有时间维度，那么您可以决定它总是成功还是总是失败(同样是406)。

提出“永远成功”的理由，你可以争辩说，非版本化的数据在任何时候都是有效的(如果它没有版本化，那么它永远不会改变)系统定义的假设是，如果数据曾经存在，那么它从你的系统宇宙开始就一直存在。例如，对UUID或序列号这样的不可变属性的请求应该(可能)总是成功的。

如果“406总是失败”，您可以声称，如果用户指定了特定日期，那么她希望获得信息的版本，而且由于所请求的资源没有版本，服务器无法满足请求，因此应该生成错误响应。

我主张一贯失败的做法。

有几件事要注意：

1. RFC 7089是信息性的，不能保证成为正式规范的一部分。
2. 您应该考虑在响应中添加一个不同的头，以确保缓存对时间限制的查询的响应是正确的。
3. 您可以在不依赖RFC 7089的情况下完成相同的行为，方法是在当前HTTP规范的约束范围内工作，并使用带有自定义媒体范围的通用接受机制。这将是定制的东西(通常不是一件好事)，但，RFC 7089也不是正式的。