我对OData很新，并尝试为以下方法找到合理的方法：
假设我们有一个BlogPost资源，而BlogPost有一个AuthorId字段。我们希望提供数据视图，其中作者只能看到他们编写的BlogPost。此外，可能存在一种关系，允许一些作者查看由其他作者写的BlogPosts - 一个父子关系，但通过其他一些实体，而不是直接。
我们一直在考虑为BlogPost资源定义这两个不同视图的一些函数。也许吧：
~/BlogPosts.ForUser(123) - gets BlogPosts where AuthorId = 123
~/BlogPosts.ForParent(123) - gets BlogPosts where the AuthorId is a child of AuthorId 123
我意识到我们可以通过某种OData过滤等来完成其中的一些（可能全部）。但是，除了创建数据的“固定”视图外，我们还想进行一些授权检查以确保用户可以访问他们要求的记录。
我们提出的似乎是一种合理的方法。然后，我们想要我们是否可以对函数的结果进行额外的OData $过滤和$ select等，并且好奇这是否有效。
最后，如果这样可行，它是否适用于为.NET Web API v2实现的OData v3。
所以问题是：
更新
我们已经回答了第二个问题。是的，您可以对功能结果进行OData过滤。我们只是在v4上取得了成功，而这种方法的“适合”问题仍然存在。
答案 0 :(得分：1)
我们最近一直在考虑同样的问题，所以我会在这里提出一个答案，当然，答案是“这是一种合理的方法吗？”真的是“是的，如果它适合你的目的”......
我们一直倾向于OData成为我们想要向第三方消费者公开的数据的只读视图。我们尝试将OData模型结构与内部域模型结构分开，即通过SQL视图，或者甚至通过具有完全独立的OData表，这些表在从我们的域实体引发事件时填充，a-la DDD + CQRS
OData似乎作为数据的读取视图非常强大。您免费获得的所有过滤，排序，聚合等都非常引人注目。并且已经有工具出现，允许您将查看器指向OData源并浏览数据 - 当您的客户想要基于X / Y / Z的报告时 - 很好 - 构建带有OData数据源的电子表格，并且他们现在可以做任何他们想要的雕塑了！
当涉及到身份验证/授权时，您可以将标准授权属性添加到端点，然后您还可以执行诸如过滤所服务的实体之类的操作 - 我们在“环形交叉路口”中执行此操作（我不想要在串行器中说“hack”...）的方式。这允许我们做一些事情，比如“好的，给我一个作者列表。现在，这个用户可以访问哪些这样的作者？抛弃其余部分。或者，不要扔掉它们，而是不要将整个序列化对象，只是序列化id和名称，而不是电子邮件地址和电话号码“。似乎工作得很好。
如果你问我，OData的过滤和扩展功能是值得的票价。我没有任何使用功能的经验，但同样，我喜欢它的灵活性，所以我真的不太需要引导消费者对数据或其他数据的看法。让他们自己做（当然除非你的消费者是你，在这种情况下，为你的生活而努力......）