All geek questions in one place

How will upgrading from verbose JSON to JSON light affect someone who looks only at data, not metadata?

Can someone explain to me briefly in plain English with a few points about what are the main differences between verbose JSON and JSON light for WCF data services? Microsoft found a document called "JSON light on a glance", but it lasts 23 pages! I'm not interested in metadata; I'm only interested in data. I know that JSON light falls on the wrapper "d". Anything else? Are data types (dates, booleans, etc.) sent in the same format?

EDIT: I understand that now Microsoft now calls JSON light simply "JSON", and JSON verbose is an old, obsolete standard. I find the new standard "JSON light" for clarity.

+2
source share
1 answer

"I'm not interested in metadata; I only care about data."

This is actually a great tagline for JSON Light in general :)

The basic principle of JSON coverage is that servers can reduce unnecessary metadata in the payload. When a client needs a specific bit of metadata (for example, the URL that it should use to edit the object), the client can generate this URI itself under the general UData URI conventions.

The client can control how much metadata the server should include in the payload by requesting one of three different levels of metadata:

  • "application / json; odata = fullmetadata" for clients who need to use metadata and do not have a way to calculate them
  • "application / json; odata = minimalmetadata" for clients who use metadata but are well versed in themselves.
  • "application / json; odata = nometadata" for clients who do not care about any metadata at all

If you are writing a client that really does not care about any metadata at all (where the metadata includes editing links, entity types, property types, stream information, navigation properties, etc.), then you can request "application / json; odata = nometadata "and you just return the properties bag.

Even if you don't need metadata, there are many differences between Verbose JSON and JSON Light. I highly recommend relying on the library for this if you are in the language where it is available (for example, in .NET there is a WCF data services client, and in Javascript there is datajs or jaydata). Here is a list of a few differences from the top of the head:

  • In OData v2, DateTimes can be represented using a "lastUpdated": "\/Date(1240718400000)\/" based format (for example, "lastUpdated": "\/Date(1240718400000)\/" ), but in v3 only JSON only supports ISO 8601 (for example, "1992-01-01T00:00:00" )
  • No more d wrappers for useful results data.
  • Instead of "results" to get the results of the collection now there is a shell "value"
  • Instead of "__count" for inline counting, JSON Light uses "odata.count"

As an example, consider the differences in the payload created by this query:

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

In comparison with this:

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

+10
source

Source: https://habr.com/ru/post/1440760/

More articles:


All Articles