谁能用简单的英语简洁地向我解释一下 WCF 数据服务的详细 JSON 和 JSON light 之间的主要区别是什么？我找到了微软的一份名为“JSON light at aglance”的文档，不过有23页那么长！我不关心元数据；我只关心数据。我知道 JSON light 会丢弃“d”包装器。还要别的吗？数据类型（日期、布尔值等）是否以相同的格式发送？
编辑：我意识到现在微软将 JSON light 简单地称为“JSON”，而 JSON verbose 是旧的、已弃用的标准。为了清楚起见，我将新标准称为“JSON light”。
“我不关心元数据；我只关心数据”
这实际上是 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 中，日期时间可以使用基于刻度的格式表示（例如，
"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
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
