我刚刚阅读了有关 OData 查询的 ASP.Net Web API 支持的信息，我在协调查询筛选的外部公开时遇到了问题，这实质上使集成商能够在不考虑最佳查询计划、不应查询的字段等的情况下向数据库抛出任意查询筛选器。
如何清理 OData 查询，以便用户无法直接向数据库抛出可怕的复杂查询，这可能会导致性能问题，并且可能包含对不应对其执行的字段的引用？
我们正在考虑解决这些问题。从 Web API RC 开始，我们要求您使用 [Queryable] 显式批注您的方法，以指示你想要选择加入自动筛选行为。我们还在研究稍后将提供的其他一些可扩展性/自定义 API。
从根本上说，由于这是一个自动系统，因此开发人员需要了解所有性能/安全注意事项。从某种意义上说，这与参数模型绑定中的过度发布问题没有什么不同（例如，有人发布了一个将 IsAdmin 属性设置为 true 的用户对象，即使您的 API 从未记录过它支持此类属性。它恰好有效，因为您在服务器上使用的模型类型也具有 IsAdmin 属性）。这些问题可以通过编写特定的DTO对象来解决，这些对象严格控制您公开并接受哪些数据作为输入。
在我看来，这是使用 OData 查询语法的体系结构权衡。 如果不希望用户具有不受约束的查询访问权限，请不要使用它。 这是相同的，SQL 视图与 SQL 存储过程参数。
Web API 具有特殊的处理程序机制。因此，您可以检查和处理来自用户的查询。
http://www.asp.net/web-api/overview/working-with-http/http-message-handlers
但是对于 OData 查询，从数据库中公开 IQueryable 并不常见。常见的方法是在服务器上进行常规查询、"预查询"，然后让用户能够查询或筛选此预查询结果。而且您将确定用户无法使查询比预查询结果"更宽"。
请注意：WebAPI 仅支持过滤器、顶部、跳过、排序。所以非常有限。对于正常的 OData 支持 - 使用 WCF 数据服务
当您想隐藏用户过滤/查询某些列时，一种方法是编写自定义处理程序，该处理程序将解析用户的 URI 并返回例如 403 错误，或者作为变体使 DTO 对象没有这些列并公开它们以供用户"预查询"。