http - Redis 如何适应 ASP.NET Web API OData 世界？

Question

如果您考虑使用 Redis 实现二级缓存的大规模解决方案，或者您的第一个数据源可能也是 Redis，我没有发现 ASP.NET WebAPI OData 实现如何与键值存储之类的东西一起工作。

我可以分析由 OData 解析器生成的表达式树并将一些过滤器转换为 Redis 操作，但是 Redis 的整体性质最适合您实现纯 REST:

• http://somesite.com/users => users(Redis 集)
• http://somesite.com/users/1 => users:11 (Redis key)

如果我想要最新的注册用户，也许我会有这样的东西:

• http://somesite.com/users/latest => users:latest(Redis 排序集)

整个问题...

OData 在这种情况下必须做什么？

Answer 1

我认为 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 完成。值(value)支柱是一样的。