RFC 8259 --- The JavaScript Object Notation (JSON) Data Interchange Format
JSON has become defacto data exchange format for REST API. It is so common that developers consider JSON as a default protocol for...
RFC 8259 — The JavaScript Object Notation (JSON) Data Interchange Format
![source: https://www.json.org/]
JSON has become defacto data exchange format for REST API. It is so common that developers consider JSON as a default protocol for communication until specified otherwise.
In this article, I will try to cover the history of JSON along with RFC and IETF.
“JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the [JavaScript Programming Language], [Standard ECMA-262 3rd Edition — December 1999]. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.” — The official definition from json.org
JSON was first introduced by [Douglas Crockfold] in 2001. Since then, JSON has been adopted by all the big tech companies like Google, Facebook, Twitter etc. Before JSON was popular, XML was a standard way for most data exchange purposes. XML is still used by many enterprise companies like Amazon AWS. Since the rise of smartphone and mobile applications, REST API and JSON have become default choice of developers.
RFC 8259 is the official and standard document used by developers to develop JSON SDK/ Libraries in different programming languages.
If you are a young developer you may have following questions.
- What is RFC?
- Who writes and approves RFC?
- Who maintains RFC?
RFC is “Request For Comments”. It’s a formal document from the Internet Engineering Task Force (IETF) created following a collaborative approach. RFCs have a long history, starting back in 1969 in ARPANET times. The Internet was created in this way, with RFCs being a starting point of discussion or protocol implementation details that people used to implement in the actual software. Mark Nottingham’s excellent article on [How to read RFCs] is a good starting point for the interested ones.
IETF is the body that defines standard Internet operating protocols, i.e. TCP/IP, WebSocket, JSON, XML, HTTP/2 and many others. IETF is invariably behind all the standards of any existing and emerging technologies in the Internet.
The IETF has a hierarchical structure with distributed activities. At the top of the hierarchy is the Internet Engineering Steering Group (IESG) largely responsible for deciding which topic areas the IETF will/won’t address in its work. The IESG defines certain topic areas such as networking or applications and recruits Area Directors (ADs) to oversee them. The Area Directors, in turn, establish charters for working groups (WGs) to define standards. Eventually, individuals — not companies — join the working groups to participate in the standards-writing process and eventually publish (and maintain) Requests for Comments (RFCs), the IETF’s standards documents.
Let’s go back to JSON and RFC 8259.
I highly recommend reading JSON RFC for a complete overview of what JSON is all about: https://tools.ietf.org/html/rfc8259
Few important lines from RFC…
JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays).
Null is a valid data type, though few libraries don’t support null properly. Consequently, JSON doesn’t have a float data type, a number can be treated as a float or integer.
An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array.
It’s important to emphasise here that an object is an unordered collection, so when you retrieve an object, the order is not guaranteed.
An array is an ordered sequence of zero or more values.
An array is an ordered sequence, so when you retrieve elements from the array it will maintain the sequence.
A JSON value MUST be an object, array, number, or string, or one of
the following three literal names:
false null true
The literal names must be lowercase. No other literal names except these 3 are allowed.
The representation of numbers is similar to that used in most
programming languages. A number is represented in base 10 using
decimal digits. It contains an integer component that may be
prefixed with an optional minus sign, which may be followed by a
fraction part and/or an exponent part. Leading zeros are not
allowed.
The number is 10 based, JSON doesn’t natively support other number systems such as binary or hexadecimal, but you can send octal or hexadecimal values as a string if you really wanted.
You can also refer the original RFC for JSON, written by Dr Crockfold in July 2006. https://tools.ietf.org/html/rfc4627
Apart from JSON, here are few interesting RFCs you may want to peruse if interested.
Http/3 - https://tools.ietf.org/html/draft-ietf-quic-http-10