缓存GET调用的RESTful API结果的最佳方法
我正在考虑在前面创建一个缓存层的最佳方式，或者作为第一层的GET请求到我的RESTful API（用Ruby编写）。
并非每个请求都可以被缓存，因为即使对于某些GET请求，API也必须验证请求用户/应用程序。 这意味着我需要配置哪个请求是可缓存的，以及每个缓存的答案有效的时间。 对于少数情况，我需要很短的到期时间，例如15秒或更短。 即使到期日尚未到达，我也应该可以让缓存条目在API应用程序中过期。
我已经想过很多可能的解决方案，我的两个最好的想法：
API的第一层（甚至在路由之前），由我自己缓存逻辑（在我手中拥有所有配置选项），答案和过期日期存储到Memcached
一个Web服务器代理（高可配置），或许像Squid的东西，但我从来没有使用过这种情况下的代理，我绝对不知道它
我也考虑过像Varnish这样的高速缓存解决方案，我使用Varnish来处理“平常”的网络应用程序，这很令人印象深刻，但配置有点特别。 但如果它是最快的解决方案，我会使用它。
另一个想法是缓存到我已经在数据层中使用的Solr索引，以便不查询大多数请求的数据库。
如果有人有提示或好消息来了解这个话题，请告诉我。
memcached是一个很好的选择，我看到你已经提到这是一个可能的选择。 另外Redis在这个级别似乎也被称赞为另一种选择。
在应用程序级别上，根据文件和/或模块对文件进行缓存的更细粒度的方法，本地存储始终是用户可能一遍又一遍地请求的常见对象的选项，即使只是简单地删除响应对象进入会话，以便可以重复使用与另外的http休息调用并适当地编码。
现在人们来回讨论清漆vs鱿鱼问题，两者似乎都有其优点和缺点，所以我不能评论哪一个更好，但很多人说，使用调整好的apache服务器进行清漆对于动态网站来说非常有用。
首先，将您的RESTful API构建为RESTful。 这意味着经过身份验证的用户也可以获取缓存的内容，以便将所有状态保留在需要包含身份验证详细信息的URL中。 当然，这里的命中率会更低，但是可以缓存。
随着大量登录用户的使用，在整页缓存后面放置某种模型缓存将是非常有益的，因为即使有些模型仍然没有共享（在良好的OOP结构中），仍然可以共享许多模型。
然后，对于整页缓存，您最好将所有请求都保留在Web服务器上，特别是远离下一步中的动态处理（在您的情况下为Ruby）。 从普通Web服务器缓存完整页面的最快方式始终是Web服务器前的缓存代理。
在我看来，清漆很好，很容易，但有些人更喜欢鱿鱼。
由于REST是一个HTTP事件，因此缓存请求的最佳方式可能是使用HTTP缓存。
在你的响应中使用ETags进行研究，在请求中检查ETag以'304 Not Modified'进行回复，如果ETags相同，则让Rack :: Cache提供缓存数据。 这对缓存控制“公共”内容非常有用。
Rack :: Cache最好配置为使用memcache来满足其存储需求。
我上周写了一篇博客文章，讲述Rack :: Cache使用ETags检测缓存内容并将其返回给新客户端的有趣方式：http://blog.craz8.com/articles/2012/12/19/rack-cache-和ETag的换偶更快，轨道
即使你没有使用Rails，Rack中间件工具也非常适合这个东西。
链接地址: http://www.djcxy.com/p/21963.html