问题描述
有人能用简单的英文简洁地向我解释一些要点吗?WCF数据服务的详细JSON和JSON light之间的主要区别是什么?我找到了Microsoft的一个名为"JSON light一目了然"的文档，但是它长达23页！我不在乎元数据；我只关心数据.我知道JSON light会丢弃"d"包装器.还要别的吗?数据类型(日期，布尔值等)是否以相同的格式发送?
Can anyone explain to me concisely in plain English with a few bullet points what the main differences are between verbose JSON and JSON light for WCF Data Services? I found a document called "JSON light at a glance" by Microsoft, but it's 23 pages long! I don't care about metadata; I only care about the data. I know that JSON light drops the "d" wrapper. Anything else? Are the data types (dates, booleans, etc) sent in the same format?
我意识到现在Microsoft现在将JSON light简称为"JSON"，而JSON verbose是已过时的旧标准.为了清楚起见，我将新标准称为"JSON light".
I realize that now Microsoft is now calling JSON light simply "JSON", and JSON verbose is the old, deprecated standard. I am calling the new standard "JSON light" for clarity.
推荐答案
我不在乎元数据；我只在乎数据"
"I don't care about metadata; I only care about the data"
对于整个JSON Light来说，这实际上是一个很好的口号:)
That's actually a great tagline for JSON Light as a whole :)
JSON light的核心原理是服务器可以减少有效负载中不必要的元数据.当客户端确实需要某些元数据(例如，用于编辑实体的URL)时，客户端可以根据通用的OData URI约定自行生成该URI.
The core principle of JSON light is that servers can cut down on unnecessary metadata in the payload. When a client does need a certain bit of metadata (for example, the URL it should use to edit the entity), the client can generate that URI itself based on common OData URI conventions.
客户端可以通过请求三种不同的元数据级别之一来控制服务器应在有效负载中包含多少元数据:
A client can control how much metadata the server should include in the payload by requesting one of the three different metadata levels:
- "application/json; odata = fullmetadata"，适用于需要使用元数据而又无法自行计算的客户
- "application/json; odata = minimalmetadata"用于使用元数据但自己可以对其进行精细计算的客户端
- "application/json; odata = nometadata"用于不关心任何元数据的客户端
如果您编写的客户端根本根本不关心任何元数据(其中元数据包括编辑链接，实体类型，属性类型，流信息，导航属性等)，那么您可以请求"/json; odata = nometadata"，您将获得一袋属性.
If you're writing a client that really doesn't care about any metadata at all (where metadata includes edit links, entity types, property types, stream information, navigation properties, etc.), then you can request "application/json;odata=nometadata" and you'll just get back a bag of properties.
即使您不关心元数据，JSON Verbose和JSON Light之间也有很多细微差别.如果您使用的是一种可用的语言，我强烈建议您使用一个库(例如，.NET中有WCF数据服务客户端，而Javascript中有datajs或jaydata).这是我脑海中几个不同之处的列表:
Even if you don't care about metadata, there are lots of little differences between JSON Verbose and JSON Light. I would strongly recommend relying on a library for this if you're in a language where one is available (for example, in .NET there's the WCF Data Services Client and in Javascript there's datajs or jaydata). Here's a list of a couple differences off the top of my head:
- 在OData v2中，日期时间可以使用基于刻度的格式表示(例如，
"lastUpdated": "\/Date(1240718400000)\/")，但是在v3 JSON中，仅支持ISO 8601(例如，"1992-01-01T00:00:00") - 结果有效载荷上不再有"d"包装器.
- 现在有了值"包装器，而不是用于收集结果的结果"包装器
- JSON Light使用"odata.count"代替内联计数的"__count"
- In OData v2, DateTimes could be represented using the ticks-based format (e.g.,
"lastUpdated": "\/Date(1240718400000)\/"), but in v3 JSON only ISO 8601 is supported (e.g.,"1992-01-01T00:00:00") - There is no "d" wrapper on results payloads anymore.
- Instead of a "results" wrapper for collection results, there is now a "value" wrapper
- Instead of "__count" for inline count, JSON Light uses "odata.count"
作为示例，请看一下此查询产生的有效负载的差异:
As an example, take a look at the differences in the payload produced by this query:
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=verbose
相对于此:
http://services.odata.org/v3/OData/OData.svc/Products?$inlinecount=allpages&$top=2&$format=application/json;odata=nometadata
http://services.odata.org/v3/OData/OData.svc/Products?$inlinecount=allpages&$top=2&$format=application/json;odata=nometadata
这篇关于从冗长的JSON升级到JSON light将如何影响仅查看数据而不查看元数据的人?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！