JavaScript Object Notation

JavaScript Object Notation
File extension :	.json
MIME type :	application / json
Standard (s) :	RFC 8259 , ECMA-404 (PDF)
Website :	https://json.org/

The JavaScript Object Notation ( JSON [ ˈdʒeɪsən ]) is a compact data format in an easily readable text form and is used for the purpose of data exchange between applications. JSON is independent of the programming language. Parsers and generators exist in all common languages.

JSON was originally specified by Douglas Crockford . It is currently specified by two competing standards - RFC 8259 and ECMA-404 .

Areas of application

JSON is used to transfer and store structured data. It serves as the data format for data transmission ( serialization ). In web applications and mobile apps in particular , it is often used in conjunction with JavaScript , Ajax or WebSockets to transfer data between the client and the server.

Data structure and format definition

Character encoding and data types

The data can be nested as required, for example an array of objects is possible, which in turn contain arrays or objects. By default, JSON uses UTF-8 as the character encoding . Also, UTF-16 and UTF-32 are possible.

JSON knows the following types of elements .

Zero value

is represented by the keyword null.

Boolean value

is represented by the keywords trueand false. These are not strings. They will therefore like null, not in quotes.

number

is a sequence of digits 0- 9. This sequence can be initiated by a negative sign - and interrupted by a decimal point . . The number can be supplemented by specifying an exponent eor E, which is followed by an optional sign + or -and a sequence of digits 0- 9.

String

begins and ends with double straight quotation marks ( "). It can contain Unicode characters and escape sequences\ initiated by it .

Array

starts with [and ends with ]. It contains an ordered list, separated by commas, of elements of the same or different types. Empty arrays are allowed.

object

starts with {and ends with }. It contains an unordered list of properties, separated by commas . Objects without properties ("empty objects") are permitted.

property

consists of a key and a value, separated by a colon ( Schlüssel : Wert). The keys should be unique, since different parsers handle duplicate keys differently. While ECMA-404 does not require uniqueness, RFC 7159 requires keys to be unique within an object.

• the key is a string .
• the value is any element .

Insignificant white space characters can be used.

restrictions

JSON does not support all data types supported by JavaScript. For unsupported data types, serialization is carried out as follows:

• NaN, Infinityand -Infinityare nullserialized to.
• Date-Objects are converted as a string into the ISO-8601 format.
• Function-, RegExp- and Error-objects are discarded.

example

{
  "Herausgeber": "Xema",
  "Nummer": "1234-5678-9012-3456",
  "Deckung": 2e+6,
  "Waehrung": "EURO",
  "Inhaber":
  {
    "Name": "Mustermann",
    "Vorname": "Max",
    "maennlich": true,
    "Hobbys": ["Reiten", "Golfen", "Lesen"],
    "Alter": 42,
    "Kinder": [],
    "Partner": null
  }
}

JSON schema

JSON schema specifies a JSON-based format to define the structure of JSON data for validation , documentation and interaction control. It contains a contract for the JSON data required for a particular application and how that data can be modified.

The JSON schema is based on the concepts of the XML schema , but is JSON-based. As in XSD, the same serialization and deserialization tools can be used for both the schema and the data. It's self-describing. It is laid down in an Internet draft by the Internet Engineering Task Force . Several validators , each with different levels of conformity, are available for different programming languages .

example

{
  "$schema": "http://json-schema.org/draft/2019-09/schema",
  "title": "Politiker",
  "type": "object",
  "required": ["Vorname", "Nachname", "Geburtsdatum", "Nationalitaet"],
  "properties":
  {
    "Vorname":
    {
      "type": "string"
    },
    "Nachname":
    {
      "type": "string"
    },
    "Geburtsdatum":
    {
      "type": "date"
    },
    "Nationalitaet":
    {
      "type": "string",
    },
    "Partei":
    {
      "type": "object",
      "properties":
      {
        "Name":
        {
          "type": "string"
        },
        "Hauptsitz":
        {
          "type": "string"
        },
        "Gründungsdatum":
        {
          "type": "date"
        },
        "Gründungsort":
        {
          "type": "string"
        }
      }
    },
    "Amt":
    {
      "type": "string"
    }
  }
}

The above JSON scheme can be used to test the validity of the following JSON:

{
  "Vorname": "Ronald",
  "Nachname": "Reagan",
  "Geburtsdatum": "1911-02-06",
  "Nationalitaet": "US-amerikanisch",
  "Partei":
  {
    "Name": "Republican Party",
    "Hauptsitz": "Washington, D.C.",
    "Gründungsdatum": "1854-03-20",
    "Gründungsort": "Ripon"
  },
  "Amt": "US-Präsident"
}

Comparison with XML

Both JSON and XML describe the structure of a data record. The data record can contain further data records, which means that structures can be nested at any depth.

The individual nodes of the data structure are named in XML, while the nodes are unnamed in JSON.

In XML, simple character strings can be described both as an attribute of an element and as a separate element; in JSON, there is no such distinction. This flexibility, which is irrelevant in most cases, means that the structure of XML documents often differs unnecessarily.

There are description languages ​​for both JSON and XML in order to further limit what "valid" documents look like, in contrast to "well-formed" documents.

The syntax of JSON is much simpler and therefore often appears more readable and, in particular, easier to write. Typically, JSON also produces less overhead compared to XML.

Both JSON and XML have to be read in by a special parser. Traditionally, every well-formed JSON document is a valid JavaScript expression, but carelessly interpreting JSON documents with eval leads to security gaps .

Both JSON and XML are not well suited for representing binary data , since both data formats are character-based as primitives and not byte-based.

For comparison, the above example in an XML form:

<Kreditkarte Herausgeber="Xema" Nummer="1234-5678-9012-3456" Deckung="2e+6" Waehrung="EURO">
  <Inhaber Name="Mustermann" Vorname="Max" maennlich="true" Alter="42" Partner="null">
    <Hobbys>
      <Hobby>Reiten</Hobby>
      <Hobby>Golfen</Hobby>
      <Hobby>Lesen</Hobby>
    </Hobbys>
    <Kinder />
  </Inhaber>
</Kreditkarte>

After removing the optional spaces, the JSON object is 226 bytes and the XML object is 279 bytes - an increase of 23%. Often attributes can also be formulated as child nodes, the example could then look like this:

<Kreditkarte>
  <Herausgeber>Xema</Herausgeber>
  <Nummer>1234-5678-9012-3456</Nummer>
  <Deckung>2e+6</Deckung>
  <Waehrung>EURO</Waehrung>
  <Inhaber>
    <Name>Mustermann</Name>
    <Vorname>Max</Vorname>
    <maennlich>true</maennlich>
    <Hobbys>
      <Hobby>Reiten</Hobby>
      <Hobby>Golfen</Hobby>
      <Hobby>Lesen</Hobby>
    </Hobbys>
    <Alter>42</Alter>
    <Kinder />
    <Partner>null</Partner>
  </Inhaber>
</Kreditkarte>

If the spaces were removed, this object would be 361 bytes in size - an increase of 60% compared to the JSON object.

JSONP (JSON with padding)

JSONP (JSON with padding)
File extension :	.jsonp
MIME type :	application / json-p
Standard (s) :	RFC 7159 , RFC 4329
Website :	json-p.org

With JSONP (JSON with padding), the JSON data is integrated via an <script>element and output including a function call. This allows the transfer of JSON data on domain boundaries , is fraught with security risks.

JSONP was introduced by Bob Ippolito in 2005 and is now supported by many Web 2.0 applications such as Dojo Toolkit , jQuery , Google Web Toolkit Applications and Web Services. Extensions have been proposed for this protocol that allow additional input parameters, such as B. JSONPP.

functionality

Ajax data queries to servers are usually made via the XMLHttpRequest object of a web browser . Due to the same-origin policy , this does not work if the website displayed in a web browser tries to access a server via this object that is located in a different domain than the website displayed. The problem can be circumvented using JSONP. In the srcattribute of an <script>element it is possible to specify any URL. The same-origin policy does not apply to this attribute. It is therefore possible to specify a URL in a different domain that returns JSON data, for example. But this script would have no effect.

In order to be able to process the JSON data on the client , the server packs them as parameters in a JavaScript function that is already defined in the web browser. The name of this function is usually communicated to the server in the query string of the URL, although the exact format or the name of the parameter is not standardized.

Example:

The JSONP data is integrated in the HTML code of a website as follows:

<script type="text/javascript"
        src="https://example.com/getjson?jsonp=exampleCallback">
</script>

The server then generates a JavaScript code snippet in which the actual data is transferred to the named function:

  exampleCallback( {"name":"Jane Doe", "value":4711} );

The browser then executes this function call as if it had been written down directly in the HTML page and can thus process the JSON data from the call.

Usually a separate <script>element is required for each JSONP call .

Security risks

<script>Elements enable a server to transmit any content (not just JSON objects) to the web browser. This can lead to a malicious web service spying out private information in the web browser via the returned data or changing it in its favor ( cross-site scripting ).

Since the <script>element does not observe the same-origin policy , a malicious website can request and evaluate JSONP data that is not intended for it ( Cross-Site-Request-Forgery ). The problem arises when sensitive data needs to be protected from third parties.

alternative

With Cross-Origin Resource Sharing (CORS), there is a comparable technology that enables access across domain boundaries, but without giving the requested resource the option of executing any JavaScript code. Both technologies require the support of the appropriate resource, with CORS being easier to implement. At the same time, CORS allows a simple restriction on the part of the resource from which origins (URLs, domains) it can be used.

Therefore, CORS is generally preferable to JSONP because CORS is simpler and more secure overall.

JSON extensions

JSON-LD is used to embed RDF data.

The Hypertext Application Language (HAL) is used to implement HATEOAS in JSON-based REST interfaces .

JSON Hyper-Schema is used to annotate data types in JSON.

JSON streaming with the three variants Line-delimited JSON (LDJSON), Newline-delimited JSON (NDJSON) and JSON lines (JSONL).

GBSON is used to annotate nucleic acid sequences ( DNA and RNA ).

Similar techniques

Hjson offers an alternative syntax which is more flexible and thus simplifies creation by humans. However, due to the lower performance, it is only recommended to use it for configuration files.

YAML is a similar data format, but a lot more complicated. YAML 1.2 can be viewed as a superset of JSON, since every JSON document can also be represented as a YAML document.

Binary JSON variants exist with BSON (Binary JSON), used u. a. by MongoDB , and with JSONB used by PostgreSQL . Google's Protocol Buffers (protobuf) follow a similar approach , which, unlike JSON or BSON, are based on a schema. The CBOR is also based on JSON and has been optimized for space-saving serialization and processing speed .

The following paragraph needs to be revised. Details should be given on the talk page. Please help to improve it , and then remove this flag.

NeXTstep and macOS use a similar technique to load or save simple object trees. They are called Property Lists there . These also allow the storage of values ​​of the types array, dictionary, boolean value, binary data, date, number and character strings. These are coded either as XML, as compact binary format or as ASCII or UTF-8.

The Tool Command Language knows dictionaries (dict), which can also contain nested, named structures. These are also structured strings. The overhead is significantly reduced compared to JSON because no colons or quotation marks are required. However, there is no clear separation between object structures (property / value) and arrays (referred to here as lists). A transfer of JSON data into a dict is therefore always clearly and easily possible, but not the other way around.

Related topics

• Gson is a Java library that converts Java objects to JSON.

Web links

Commons : JavaScript Object Notation  - collection of images, videos and audio files

• json.org/json-de.html - German introduction on the official JSON page (other languages ​​available)
• Speeding Up AJAX with JSON Introduction to JSON, in which the differences to XML are worked out (English)
• Parsing JSON is a Minefield - Overview of the different standards and implementations
• JSON Viewer Online platform for formatting, validating and exchanging JSON data (English)
• jsonp.eu - Explanations and programming examples for JSON with Padding (JSONP)

Individual evidence

1. ^ Douglas Crockford: The JavaScript Object Notation (JSON) Data Interchange Format . 2017 (English, online [PDF; accessed on January 5, 2017]).
2. ↑ ECMA International (Ed.): The JSON Data Interchange Format . 2013 (English, online [PDF; accessed April 22, 2014]).
3. ↑ RFC 4627  - The application / json Media Type for JavaScript Object Notation (JSON) . July 2006. Section 2: JSON Grammar. (English).
4. ↑ JSON scheme
5. ↑ web archive ( Memento from March 4, 2016 in the Internet Archive )
6. ↑ Remote JSON - JSONP . In: from __future__ import * . Bob.pythonmac.org. December 5, 2005. Retrieved January 23, 2011.
7. ↑ jQuery API . Retrieved January 23, 2011.
8. ↑ GWT Tutorial: How to Read Web Services Client-Side with JSONP . In: Google Web Toolkit Applications . February 6, 2008. Archived from the original on January 17, 2013. Retrieved January 23, 2011.
9. ↑ Jonas Almeida: JSON, JSONP, JSONPP? . S3DB. June 11, 2008. Retrieved January 23, 2011.
10. ^ Jeremiah Grossman: Advanced Web Attack Techniques using GMail . January 27, 2006. Retrieved January 23, 2011.
11. ^ Mike Kelly: JSON Hypertext Application Language. IETF Network Working Group, October 12, 2016, accessed December 7, 2016 . 
12. ↑ Austin Wright, Geraint Luff: JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON. IETF , August 13, 2016, accessed December 7, 2016 . 
13. ↑ GBSON. A new annotation file format based on JSON. Retrieved November 24, 2019 . 
14. ↑ YAML Ain't Markup Language (YAML ™) Version 1.2
15. ↑ bsonspec.org
16. ↑ PostgreSQL 12 Documentation, 8.14. JSON types
17. ^ What Are Protocol Buffers?
18. ^ Protocol Buffers - Google's data interchange format
19. ↑ CBOR - Concise Binary Object Representation | Overview. Retrieved February 16, 2019 . 
20. ↑ Introduction to Property Lists. In: developer.apple.com. Retrieved November 6, 2011 .