将 HTTP 用于 REST API：自动缓存？答案

【问题标题】：Using HTTP for REST API: automatically cacheable?将 HTTP 用于 REST API：自动缓存？
【发布时间】：2014-10-27 13:31:44
【问题描述】：

我想知道，要制作“RESTful API”，您需要满足下面列出的 6 个架构约束：

http://en.wikipedia.org/wiki/Representational_state_transfer#Architectural_constraints

当您通过 HTTP 协议创建 REST API 时，是否会自动满足“可缓存”约束？因为 HTTP 已经通过 HTTP 标头提供了“开箱即用”的缓存系统：http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html

所以不用再担心了吗？

也许听起来是个愚蠢的问题，但我想确定一下。 :-)

亲切的问候！

【问题讨论】：

标签： api rest http caching

【解决方案1】：

让我稍微扩展一下创建正确缓存逻辑的挑战：通常，API 的后端是一个包含各种小信息的数据库。 REST API 中的典型表示可以是累积视图（比如说，用户活动日志，其中包含门户中最后用户操作的列表，类似于这些内容）。现在，为了知道您的 API URL /user/123/activity 是否已更改（在客户端在“If-modified-since”-header 中发送给您的时间戳之后），您必须检查是否有任何最后一次请求后的其他活动。这样做的开销可能与简单地再次获取结果相同。因此，在很多情况下，人们根本不会真正打扰，这很可惜，因为适当的缓存会对 Web 应用程序的性能产生巨大影响。

也许这会提供更多细节，一月

【讨论】：

我明白了，感谢您的澄清！ :-) 网上有很多关于如何通过 HTTP 正确缓存资源的资料，以进一步帮助我。

【解决方案2】：

您是对的，HTTP 已经为您提供了识别可缓存元素的方法，但是由于您的 API 将由某些服务器端逻辑生成，您仍然需要确保您的 API“后面”的代码正确HTTP 标头，并准备好并能够在理想世界中对“If-modified-since”请求做出反应。创建可靠的“最后修改”时间戳并可靠地检查它实际上是一项壮举；-)

希望这会有所帮助，一月

【讨论】：

谢谢！ :-) 你所说的“相当了不起”是什么意思？实施这个是一个挑战吗？
挑战在于时间过去了，并且存在网络延迟（以及外部因素）来验证时间戳。还有安全问题。