从详细的JSON到JSON光的升级如何影响只查看数据而不是元数据的人？

Question

任何人都可以用简单的英语简明扼要地向我解释几个要点，WCF数据服务的详细JSON和JSON之间的主要区别是什么？微软发现了一个名为“JSON light一目了然”的文档，但它长达23页！我不关心元数据;我只关心数据。我知道JSON灯会掉落“d”包装。还要别的吗？数据类型（日期，布尔值等）是否以相同的格式发送？

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

Answer 1

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

这实际上是整个JSON Light的一个很好的标语：）

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

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

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

如果您正在编写一个根本不关心任何元数据的客户端（元数据包括编辑链接，实体类型，属性类型，流信息，导航属性等），那么您可以请求“应用程序” / 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