ODATA 中多级导航的正确 Uri 语法是什么？答案

【问题标题】：What is the right Uri syntax for multilevel navigation in ODATA?ODATA 中多级导航的正确 Uri 语法是什么？
【发布时间】：2014-02-18 05:42:33
【问题描述】：

我有一个 ODATA 服务 MyService，其中包含实体客户、产品和类别，其中导航属性定义为从客户到产品，以及从产品到类别。

我对从客户到产品到类别进行导航的正确形式的 Uri 感到困惑。

最初我给了 MyService/Customers(1)/Products(10)/Categories，但它给了我一个错误。

然后我尝试了运行正常的 MyService/Customers(1)/Products/Categories。我在互联网上看到了很多我最初尝试过的 uri 形式的示例，但它对我不起作用。

谁能解释一下？

【问题讨论】：

标签： odata

【解决方案1】：

URI 的正确形式取决于导航属性 Products 的多样性。如果一个客户可以有多个产品，那么第一种形式是正确的。如果客户最多只能拥有一种产品，那么第二种形式是正确的。

也许在您的服务中，此导航属性的多重性设置不正确。

【讨论】：

看起来不错。产品多重性设置为1。但即使如此，第一个也必须给出错误吗？考虑到 id 正确地给出为 1？
作为格式错误的 URL，它应该这样做，是的。规范对这两种情况进行了特殊区分，定义了语法生成 entityNavProperty-et 以实现对单个实体的导航，特殊的 navPath-np 是在这种情况下遵循它的变体。我一直认为“np”代表“无括号”，以强调此时不允许使用。

【解决方案2】：

使用括号指定资源键表示这是一个 OData v4 主题。

根据规范OData v4: 4.3.3 URLs for Related Entities with Referential Constraints，只要Porducts 是一个集合类型，您的语法就是合规的。

为将来有问题的资源添加相关的$metadata，以解决这种程度的歧义。

如果您的第二种形式的 URL 有效，那么它通常表明 Products 导航属性的多重性是单数的，使其不再是一个集合，因此您无法通过键进行过滤。在这种情况下，如上所述，您可以使用$filter 查询选项，但您不妨直接查询Categories 控制器。

即使语法兼容并且到Products 的资源导航是一个集合，在许多实现中，这种导航的特殊性是不受支持的。可能是因为它是不必要的，但可能是因为它在意图方面是一个灰色区域，因此代码框架很难在默认情况下强制执行该区域的路由约定或规则。

例如，该查询应该由Customers 控制器评估，但返回Category 资源的集合，还是应该由Products 控制器评估以返回Category 资源的集合？如果Category 控制器是返回和查询Category 资源的控制器，而不是潜在地为所有Customer、Product 和@ 添加相同的支持，那么设计底层控制器不是更容易吗？ 987654336@控制器？

鉴于10 的唯一键 已为预期的Product 资源返回提供，1 的Customer 键无关紧要.

如果您想故意返回带有 key 为 10 的 Product 资源，但仅当它属于带有 的 Customer >key of 1 然后您还可以按以下形式指定该查询：

~/MyService/Products(10)/Categories?$filter=Product/CustomerFK eq 1
~/MyService/Products(10)/Categories?$filter=Product/Customer/PK eq 1

或者您可以直接查询类别控制器：

~/MyService/Categories?$filter=Products/any(p:p/Customer/PK eq 1 and p/Category/PK eq 10)

虽然服务作者可以选择支持多级导航，正如规范建议和 OP 所尝试的那样，但它并不总是提供开箱即用，因此我们往往会忘记实现它.这并不总是很难做到，通常我们只需要实现一些简单的路线，但由于解释和实现的可变性，我个人只支持导航 1 级深度但不允许 key 选择器在儿童级别。

如果您查询的服务不支持它，那么只需通过Cateogry 直接定位Category 资源，或通过带有适当过滤器的Product 控制器间接定位。

【讨论】：