JSONとXMLの違い

起源：マークアップ言語とデータフォーマット

XMLの祖先はSGMLで、その設計目標はドキュメント――段落、強調、構造が混ざった文章――をマークアップすることでした。だからこそ、2つのうち混合コンテンツ――<title>Learning <em>XML</em></title> のようなインラインマークアップ入りのテキスト――をサポートするのはXMLだけですし、属性や実体参照、重厚な処理モデルが育ったのもXMLです。JSONは2001年頃にJavaScriptのオブジェクトリテラルから切り出され、目的はただ一つ：可能な限り小さい文法でプログラム間の構造化データを運ぶことでした。JSONに混合コンテンツはなく、実体の仕組みも、ドキュメントツリーもありません――オブジェクト、配列、そして4つのスカラー型がすべてです。

構文：タグのコスト、属性、そして存在しない配列

XMLのすべての要素は開始と終了を持つため、単純な値1つに2つのタグがかかります：<price>19.99</price>。XMLには別の書き方――<price currency="EUR">19.99</price>――もあり、属性にするか要素にするかという選択は、20年間にわたり決定打のない議論を生んできました。JSONはキー／値のペアに書き方が1通り、リストにも1通りしかありません。決定的なのは、JSONに配列が組み込みである一方、XMLには配列型がまったくないことです。リストは要素の繰り返しで表現されるため、あらゆるJSON→XMLツールが、繰り返し項目の命名とラップの規約で合意しなければなりません。

スキーマと名前空間：XMLが依然として力を発揮する領域

XSDはエンタープライズにおけるXMLの地味な強みです。派生型、出現数の制約、パターンのファセット、そして文書を検証し「どの要素がどの規則に違反したか」を正確に報告できる20年分のツールを備えた、成熟したスキーマ言語です。JSON Schemaは違う形で同じ目的を追求しています――表現力があり、条件分岐をサポートし、現代のAPIの事実上の契約言語となっています――しかし長いドラフトの歴史のせいで、何を受け入れるかはツールによって差が大きくなります。どちらのエコシステムも厳格になれます。XMLのほうが単純に古いだけです。

名前空間はXMLのもう一つの長所です。XHTMLページは、各語彙が自分のURIを持つおかげで、キーの衝突なしにSVGやMathMLを埋め込めます。JSONには相当する機構がありません――名前の衝突は、規約や、JSON-LDのように文脈を明示的に添える階層化された設計によって避けられます。

サイズ、ストリーミング、そしてどちらを選ぶか

同じデータでもXMLのペイロードは通常大きくなります。終了タグだけで要素のマークアップはほぼ2倍になり、属性を多用するスタイルはさらに増えます。どちらのフォーマットもgzipでよく圧縮できます――XMLの冗長性は高度に圧縮可能です――しかし元のオーバーヘッドが完全に消えることはまれです。ストリーミングでは、XMLのパーサーエコシステムのほうが深いところまで根を張ります。SAXやStAXのようなプッシュ型パーサーは、メモリに載らない大きさのドキュメント向けに設計され、あらゆるプラットフォームに搭載されています。JSONのストリーミングパーサーも存在し優秀ですが、ドキュメント全体を一度に解析するのが依然として一般的な既定です。

プログラム同士がやり取りするものにはJSONを選びましょう：Web API、モバイルAPI、構造化ログ、サービス間のペイロードです。仕様が義務付けているとき――SOAPスタック、出版パイプライン、Officeフォーマット、医療や金融の多くの標準規格――、あるいはXSD検証と名前空間を通信経路で必要とするときにはXMLを選びましょう。指針はきれいに反転します。ドキュメントパイプラインに紛れ込んだJSONはたいていXMLであるべきで、SOAP時代のAPIがきれいなJSONを公開するのは裏切りではなく移行の勝利です。