2

谁能用简单的英语简明扼要地向我解释一下 WCF 数据服务的详细 JSON 和 JSON 灯之间的主要区别是什么？我找到了微软的一篇名为《JSON light at agnition》的文档，但它有 23 页长！我不关心元数据；我只关心数据。我知道 JSON 灯会丢弃“d”包装器。还要别的吗？数据类型（日期、布尔值等）是否以相同的格式发送？

编辑：我意识到现在微软现在将 JSON light 简单地称为“JSON”，而 JSON 详细是旧的、已弃用的标准。为了清楚起见，我将新标准称为“JSON light”。

4

1 回答 1

10

“我不关心元数据；我只关心数据”

这实际上是整个 JSON Light 的一个很好的标语 :)

JSON light 的核心原理是服务器可以减少负载中不必要的元数据。当客户端确实需要某些元数据（例如，它应该用来编辑实体的 URL）时，客户端可以根据常见的 OData URI 约定自行生成该 URI。

客户端可以通过请求三个不同的元数据级别之一来控制服务器应在有效负载中包含多少元数据：

  • "application/json;odata=fullmetadata" 适用于需要使用元数据但无法自行计算的客户
  • "application/json;odata=minimalmetadata" 适用于使用元数据但可以自己计算的客户
  • "application/json;odata=nometadata" 适用于不关心任何元数据的客户

如果您正在编写一个根本不关心任何元数据的客户端（其中元数据包括编辑链接、实体类型、属性类型、流信息、导航属性等），那么您可以请求“application/json; odata=nometadata”，你只会得到一袋属性。

即使您不关心元数据，JSON Verbose 和 JSON Light 之间也有很多细微差别。如果您使用的语言可用，我强烈建议您为此依赖库（例如，在 .NET 中有 WCF 数据服务客户端，在 Javascript 中有 datajs 或 jaydata）。这是我脑海中的一些差异的列表：

  • 在 OData v2 中，DateTimes 可以使用基于刻度的格式（例如，"lastUpdated": "\/Date(1240718400000)\/"）来表示，但在 v3 JSON 中，仅支持 ISO 8601（例如，"1992-01-01T00:00:00"）
  • 结果有效负载上不再有“d”包装器。
  • 现在有一个“值”包装器，而不是收集结果的“结果”包装器
  • JSON Light 使用“odata.count”代替“__count”进行内联计数

例如，看一下此查询产生的有效负载的差异：

http://services.odata.org/v3/OData/OData.svc/Products?$inlinecount=allpages&$top=2&$format=application/json;odata=verbose

与此相反：

http://services.odata.org/v3/OData/OData.svc/Products?$inlinecount=allpages&$top=2&$format=application/json;odata=nometadata

于 2013-06-21T21:40:20.673 回答