如果您考虑使用 Redis 实现二级缓存的大规模解决方案，或者您的第一个数据源也是 Redis，我不知道 ASP.NET WebAPI OData 实现如何与键值存储之类的东西一起工作。
我可以通过 OData 解析器分析生成的表达式树并将一些过滤器转换为 Redis 操作，但是当您实现纯 REST 时，Redis 的整体性质最适合：
http://somesite.com/users => users（Redis 集）http://somesite.com/users/1 => users:11（Redis 密钥）如果我想要最新的注册用户，也许我会有这样的东西：
http://somesite.com/users/latest => users:latest（Redis 排序集）在这种情况下 OData 需要做什么？
【问题讨论】：
标签： http rest asp.net-web-api redis odata
我认为 Redis 在 OData 环境中非常有用。我想首先我要解决一个认知问题：OData 不是“纯 REST”。当然，REST 可能意味着很多东西，因为它的标准很少。在大多数情况下，REST 已经意味着 JSON over HTTP/S，使用映射到实体操作的标准 HTTP 动词。 OData 只是简单地接受它，为其添加一些更正式的定义，并向其添加一个标准元数据层（如果您愿意，可以选择忽略它）。因此，我将 OData 称为“JSON++”。我不认为我见过不支持 JSON 的 OData 实现，但如果未指定 JSON，许多默认为 Atom。那么，当使用 JSON 与 OData 交互时，有什么不是“纯 REST”吗？
也就是说，我看到了在 OData 世界中与 Redis 交互的两种有趣方式。为 Redis 构建 OData 前端是可能的，甚至是有趣的。我想这不会是微不足道的，但它应该是可能的。我不知道有人这样做，但可能有。例如，有一个 Node.js 的 OData 提供程序，也许有人为 Redis 做了一些事情。
但即使使用普通的 Redis，也应该只是使用 OData URL 作为 redis 键（无论如何您似乎都倾向于使用它）——在查询级别缓存结果。这似乎是您在示例中说明的内容。由于您正在缓存数据，因此您可能希望在插入条目后使用 EXPIRE 命令来管理缓存结果的生命周期。如果您想变得更花哨，可以查看预填充 redis 缓存的策略。
您提到了更精细地使用 redis 的可能性，因此需要您解析查询等。当然，您可以在实体级别使用 redis 缓存并在其之上完全实现所有 Odata。就个人而言，我不确定这是否值得复杂。我喜欢在查询结果的粒度上使用 redis 的想法。
对您的问题的简短回答： 您可以使用 REST/JSON+Redis 完成的任何操作，都可以使用 OData+Redis 完成。价值道具是一样的。
【讨论】：