【问题标题】:JSON request payload with collection navigation properties?具有集合导航属性的 JSON 请求有效负载?
【发布时间】:2012-01-26 22:13:31
【问题描述】:

OData JSON 协议(任何版本)是否支持包含单个实体(即未批处理)的请求负载,该实体包含导航属性,其中导航属性包含一组延迟条目?

我研究了规范,看起来这没有定义,或者至少没有为版本 2 和 3 定义...

2.2.6.3.2 实体集(作为 JSON 数组) “实体集合的 JSON 表示的语法由语法定义 本节所列。语法规则“entitySetInJson”定义了 1.0 版 JSON 表示的实体集合,可能 可用于请求和响应有效负载。语法规则 "entitySetInJson2" 定义 2.0 版和 3.0 版 JSON 仅用于响应有效负载的实体集合的表示。 1.0 版和 2.0 版之间没有变化或 3.0 版格式,用于由定义的请求有效负载 本规范。”

2.2.6.3.10 链接 链接集合的 JSON 表示的语法是 由本节列出的语法定义。语法规则 “linkCollJson”定义了 1.0 版本的 JSON 表示 可用于请求和响应的链接集合 有效载荷。语法规则“linkCollJson2”定义了版本 2.0 和 用于响应的链接集合的 3.0 版 JSON 表示 仅有效载荷。本规范没有定义版本 2.0 或 3.0 版 链接集合的 JSON 表示,用于 请求有效负载。

对我来说,这表明在 OData V1 中可以上传一个对象,其 URI 值归因于它的集合导航属性,而在 V2 和 V3 中这是不可能的。 ATOM 序列化没有提出这种区别。

我的理解是否正确,或者我错过了什么。谁能提供一些关于上述更改原因的背景信息?

非常感谢。

埃里克

【问题讨论】:

    标签: json collections properties navigation odata


    【解决方案1】:

    此时规范有点不清楚,但是当它说没有为请求有效负载指定 2.0 和 3.0 版本时,这意味着在请求有效负载中您应该使用有效负载的 1.0 版本,因为没有新版本被定义。 可以插入具有扩展导航属性的新实体,其中包含实体集合。例如,您可以插入一个新类别以及属于该类别的 5 个产品。 延迟链接也是可能的,其作用是将新实体绑定到这些链接引用的现有实体。 但请注意,WCF 数据服务目前仅支持插入 (POST),它不支持更新 (PUT/MERGE/...)。

    【讨论】:

    • 谢谢 Vitek。我们没有使用 WCF,而是在我们自己的 MVC 框架中使用 MSFT OData 库。这使我们也可以支持 PUT/MERGE (& PATCH)。我确实注意到,如果我选择 ODataVersion.V1,那么库会解析包含集合导航属性的主体,而对于 V2|V3,它会失败。 IOW 该功能似乎已从 OData 中删除。我一直犹豫是否要依赖 V1 行为,原因有两个。首先,随着时间的推移,它似乎会失去对客户端框架的支持;其次,我们可能需要在并发请求中使用 V2|V3 功能。
    • 我不知道您使用的是哪个版本的库(请尝试 10 月份的最新 CTP)。在任何情况下,扩展导航属性在请求负载中的读取方式都发生了变化,尤其是在 JSON 中(以与当前的 WCF DS 行为保持一致)。无论如何,看看哪些有效负载在 V1 中有效而在 V2/V3 中无效,将会很有趣。
    • 我们使用的是 2011 年 2 月 11 日的“alpha”版本:odata.codeplex.com/releases/view/60787 这是对 2010 年 10 月 27 日版本(我们开始使用)的更新。
    • 有更新的版本吗?如果我们不为数据服务版本标头提供版本 1,则序列化程序将抛出以下内容:“尝试使用提要包装器对象读取提要的开头时,从 JSON 阅读器读取了类型为 'StartArray' 的节点。需要一个“StartObject”节点。”
    • 请尝试最新的 CTP:blogs.msdn.com/b/astoriateam/archive/2011/10/13/… 那里可能已经修复,请告诉我。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-10-14
    • 2017-06-26
    • 2017-02-01
    • 1970-01-01
    • 2018-07-22
    相关资源
    最近更新 更多