我有一个站点正在为来自多个客户端（浏览器、其他应用程序、unix shell 脚本、python 脚本等）的相同资源的 JSON 表示进行相当困难的轮询。
我想添加一些缓存，以便一些资源在服务器中缓存一段可配置的时间，以避免处理请求和将资源序列化为 JSON 的 CPU 命中。我当然可以自己将它们缓存在处理程序中，但随后会对每个请求进行序列化处理，并且还必须修改处理程序的负载。
我查看了 openrasta-caching 模块，但认为这仅用于控制浏览器缓存？
那么，在编解码器生成资源之后，如何让 openrasta 缓存资源的呈现表示有什么建议吗？
谢谢
openrasta-caching 确实初步支持服务器端缓存，通过 API，您可以使用 ServerCaching 属性映射到 asp.net 服务器端缓存。也就是说，它并不完整，openrasta-caching 也不完整。这是一个 0.2，需要几天的工作才能使其成为一个好的 v1，它完全支持我想要支持的所有场景，而 asp.net 缓存基础设施目前不支持（主要是使 OpenRasta 中的缓存工作就像一个 http 中介，而不是像 asp.net 领域那样以对象和 .net 为中心的中介，包括在您希望允许客户端强制服务器重做查询的时候，客户端对服务器缓存的控制）。由于我目前没有致力于缓存的客户项目，因此很难证明对该插件的任何进一步工作是合理的，所以我现在没有为它编码任何东西。不过，我确实有 4 天的空闲时间，所以如果您希望将 openrasta-caching 提升到 0.3，并且满足 4 天工作的任何要求，请私信我。
您可以使用 IOperationInterceptor 实现更简单的东西并使用它插入 asp.net 管道，或者更加网络友好并使用 squid 实现进程外缓存并依靠 openrasta-caching 生成正确的 http 缓存指令。
也就是说，对于您的问题，如果成本是 json，您甚至可能不需要服务器缓存。如果您将最后修改或 Etag 映射到处理程序返回的内容，它将在适当的304地方正确生成 a，并一起绕过 json 渲染，前提是您的客户端执行条件请求（并且应该这样做）。
还有一个提议的 API，允许您通过对 last modified/etag 进行第一次查询以返回 304 而不检索任何数据来进一步优化您的 API。