Reputation:
I was looking at this question
What is JSON and why would I use it?
I am confused between different names given to JSON structures
Example 1 : what is this called
{
"MIT_COLLEGE": [
{
"_id": 1,
"StudentName": "Sam",
"Student_Age": "24",
"Student_phone": "8725436232",
"Student_sex": "Male",
},
{
"_id": 2,
"StudentName": "kira",
"Student_Age": "22",
"Student_phone": "8725136232",
"Student_sex": "Female",
}
],
"CAMBRIDGE_COLLEGE": [
{
"_id": 1,
"StudentName": "Paul",
"Student_Age": "26",
"Student_phone": "87333336232",
"Student_sex": "Male",
},
{
"_id": 2,
"StudentName": "michael",
"Student_Age": "22",
"Student_phone": "872115436232",
"Student_sex": "Male",
}
]
}
Example 2:: what is this called
{
"_id": 2,
"StudentName": "michael",
"Student_Age": "22",
"Student_phone": "872115436232",
"Student_sex": "Male",
}
Other possible structures in JSON and what is it called ?
Thanks ... hope i am clear
Upvotes: 2
Views: 12660
Reputation: 9230
One other thing should be noted: all these definitions of JSON allow names (in name/value pairs) that are not valid property names in Javascript, e.g. field names cannot start with a digit or symbol in Javascript objects, and cannot contain a space, but names in JSON name/value pairs can contain any character (possibly escaped). So the name JSON is a bit misleading -- it's more of an associative array than a representation of a Javascript object.
Upvotes: 0
Reputation: 24637
The only differences are between the specifications:
Here are the differences:
Insignificant whitespace is allowed before or after any of the six structural characters.(RFC 4627)
Insignificant whitespace is allowed before or after any token.(ECMA-404)
JSON text SHALL be encoded in Unicode. The default encoding is UTF-8. (RFC 4627)
A JSON text is a sequence of tokens formed from Unicode code points that conforms to the JSON value grammar. (ECMA-404)
Implementations MUST NOT add a byte order mark to the beginning of a JSON text. (RFC7159)
Objects in I-JSON messages MUST NOT have members with duplicate names. (RFC7493)
Each line is valid JSON with \n
line separators (ndJSON)
And the reasoning behind them:
RFC4627
The ECMA standard is minimal, describing only the allowed grammar syntax, whereas the RFC also provides some semantic and security considerations.
RFC7159
There was considerable grumbling in the IETF over JSON specs and in particular RFC4627. First of all, it was "Informational" rather than "Standards track" which meant there were bureaucratic problems referring to it in certain contexts. Secondly, it and the ECMA version were inconsistent in that 4627 required a JSON text to be either an object or a list, whereas the ECMA version was fine with just "42" or true. Finally, 4627 allowed a few things, like duplicate keys in objects and broken Unicode strings, that everyone agrees are bad practices.
So the IETF spun up a JSON Working Group in 2013 with the objective of revising 4627 to fix these problems.
RFC7493
I-JSON is just a note saying that if you construct a chunk of JSON and avoid the interop failures described in RFC 7159, you can call it an "I-JSON Message". If any known JSON implementation creates an I-JSON message and sends it to any other known JSON implementation, the chance of software surprises is vanishingly small.
JSON is starting to be used a lot in security-related protocols: Crypto, authentication/authorization, and so on. It turns out that the security people worry about Bad People and Government Employees using Stupid JSON Tricks like duplicate keys and carefully-malformed Unicode to attack these protocols.
So if you specify that your payload MUST be I-JSON message, and the receiver checks that, there’s one particular class of attacks that you no longer have to worry about.
ndJSON
A common use case for ndJSON is delivering multiple instances of JSON text through streaming protocols like TCP or UNIX Pipes. It can also be used to store semi-structured data.
eJSON
eJSON is an extension of JSON to support more types. It supports all JSON-safe types, as well as:
Date (JavaScript Date) Binary (JavaScript Uint8Array or the result of EJSON.newBinary) User-defined types
All eJSON serializations are also valid JSON. For example an object with a date and a binary buffer would be serialized in EJSON as:
{
"d": { "$date": 1358205756553 },
"b": { "$binary": "c3VyZS4=" }
}
References
Upvotes: 2
Reputation: 121849
JSON is JSON.
Douglas Crockford says it best:
http://www.json.org/fatfree.html
JSON (or JavaScript Object Notation) is a programming language model data interchange format. It is minimal, textual, and a subset of JavaScript. Specifically, it is a subset of ECMA-262 (The ECMAScript programming Language Standard, Third Edition, December 1999). It is lightweight and very easy to parse.
JSON is not a document format. It is not a markup language. It is not even a general serialization format in that it does not have a direct representation for cyclical structures, although it can support a meta representation that does. ...
With no other effort on my part, JSON has been widely adopted by people who found that it made it a lot easier to produce distributed applications and services. The original page has been translated into Chinese, French, German, Italian, Japanese, Korean, and Spanish. JSON has been formalized in RFC 4627. The MIME Media Type is application/json.
The types represented in JSON are strings, numbers, booleans, object, arrays, and null.
It's really no more, and no less, than a few specific constructs from the Javascript programming language. Those constructs (as stated above) are ONLY the following:
Both examples you cited above are simply "JSON".
You can find out more here:
www.json.org
Upvotes: 2