XMLは、タグ、名前空間、スキーマという文法を機械間のデータに与えた。表現力は豊かだが、単純なレコードを送るだけでも文書を書く必要があるほど重かった。JSONは逆の道を進んだ。そのホームページが述べているように、JSONは2つの構造、すなわち名前と値のペアの集合と値の順序付きリストに基づいており、C、C++、C#、Java、JavaScript、Perl、Pythonのプログラマーにはすでになじみ深い慣習で書かれている。だからこそ、それらのページはJSONを理想的なデータ交換言語と呼んでいる。

この形式の系譜とJavaScriptからの脱却は、いずれもその標準化の過程に現れている。RFC 8259「The JavaScript Object Notation (JSON) Data Interchange Format」は、ECMAScriptで定義されたJavaScriptのリテラルに由来する、軽量でテキストベースかつ言語非依存のデータ交換形式を説明している。それはあらゆるウェブブラウザーが認識できるが、どのブラウザーも所有しているわけではない。IETFのJSONワーキンググループはRFC 7159を経てRFC 8259へとこれを進め、2017年12月にJSONをインターネット標準とした。

その結果は置き換えだった。かつてAPIがXMLスキーマを交渉していたところで、今ではどのプログラマーでも一目で読めるオブジェクトや配列を返す。標準化のプロセスが採用者を募る必要があったのではなく、採用された後に初めて標準化のプロセスに到達した形式である。

あらゆるAPIにとって2つの構造で十分である

オブジェクトと配列という2つの構造は、プログラムがシステム間で受け渡すほとんどすべてのデータ形状に組み合わせられるため、この形式には拡張機構が不要だった。

構文をJavaScriptのリテラルから導き出したことで、この形式は最も急速に成長する開発者層にとって即座に読みやすくなり、言語非依存であることで他のあらゆるコミュニティも内側にとどまった。

スキーマもタグの語彙も不要だったため、APIは文書型定義を調整することなくペイロードを変更できた。

採用後にIETFを通じて標準化されたことで、前身を魅力のないものにした重さを課すことなく相互運用性が確固たるものになった。

形式は引き算によって勝つ。構築要素が少なければ意見の相違も少なくなり、どのプログラマーでも文書なしで読めるデータ形式は、より豊かな前身たちを停滞させた抵抗を取り除く。

RFC 8259は2017年12月にJSONを公式のインターネット標準としたが、その時点でJSONはすでにウェブAPI、設定、ログデータの既定の交換形式となっていた。形式がワーキンググループによって標準化され、それが世界の既存の慣行を追認するという珍しい事例である。

出典をたどる

出典

  1. RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format IETF (Datatracker) · datatracker.ietf.org ·
  2. Introducing JSON json.org · json.org