JSON vs XML: 主要な違い、強み、使用例

Scrapeless Scraping APIは、JSONまたはCSVで構造化されたウェブデータを返し、JSONがXMLと比較する際の自然なアプリケーション対面の参照ポイントとなります。

JSONとXMLの違いは何ですか？

JSONとXMLは構造化された情報を表現するテキスト形式ですが、その情報を異なる方法で記述します。JSONはオブジェクト、配列、文字列、数値、真偽値、nullを通じて値をモデル化します。XMLは属性、テキスト、子要素、コメント、および処理命令を含む可能性のある要素のツリーとして文書をモデル化します。その区別は句読点よりも重要です: JSONはアプリケーションデータから始まり、XMLはデータレコードと豊富に構造化された文書の両方を表現できます。

正式なJSON文法は意図的に小さいです。 RFC 8259は、JSONオブジェクト、配列、数値、文字列、ブール値、およびnullを定義しています。、相互運用性ルールとともに交換されたJSONテキストのための。XMLはより広範なドキュメントモデルを持っています。 W3C XML仕様 要素、属性、エンティティ、文字データ、文書宣言、および正確性の制約を定義します。

典型的なRESTレスポンスに、製品、ユーザー、または検索結果が含まれている場合、JSONは通常、アプリケーションコードが辞書、マップ、配列、または構造体に解析できる直接的な表現を生成します。XMLは、契約が複数の語彙からの修飾された名前、インラインマークアップを含む順序付きの文、またはXMLスキーマと変換を中心に構築されたシステムとの互換性を必要とする場合に魅力的になります。

データモデルの違い

JSON には値モデルがあります。オブジェクトは名前付きメンバーを含み、配列は順序付けられた値を含みます。オブジェクトメンバーの順序はビジネス意味を持つべきではなく、なぜなら消費者はオブジェクトメンバーを異なる順序で公開する可能性があるからです。配列は明示的に順序付けられています。JSON プロパティは、テキストコンテンツと属性の違いを直接区別することはできません。なぜなら JSON には属性の概念がないからです；アプリケーションは独自の規約を作成する必要があります。

XMLにはノードモデルがあります。要素は名前を持ち、属性を持つことができ、テキストを含むことができ、子を含むことができます。子ノードの順序には意味があり、これによりXMLはインラインの強調、リンク、引用、および埋め込まれたドメイン要素を含む段落を、文章をアプリケーション固有のフィールド規約にフラット化することなく表現することができます。名前空間により、2つの語彙が衝突することなく同じローカル要素名を使用することができます。

JSONとXMLの構文を並べて表示

A JSON レコード

このJSONオブジェクトは、ネストされたサプライヤーとタグの配列を持つ1つのカタログアイテムを表しています：

{
  "id": "A-104",
  "name": "Desk Lamp",
  "available": true,
  "supplier": { "country": "DE", "name": "Nordlicht" },
  "tags": ["lighting", "desk"]
}

プロパティ名はフィールドラベルを保持し、JSONリテラルは真偽値とnull値を保持します。パーサーは区別するための別の規則を必要としません。 true 文字列から "true".

同等のXMLレコード

XML表現は、識別子を属性に置き、残りの値を要素として表現できます：

<item id="A-104" available="true">
  <name>Desk Lamp</name>
  <supplier country="DE">Nordlicht</supplier>
  <tags>
    <tag>lighting</tag>
    <tag>desk</tag>
  </tags>
</item>

XML バージョンはより長いですが、属性を通じてメタデータを添付でき、名前空間で修飾された要素でドキュメントを拡張できます。スキーマがなければ、テキスト true は語彙的内容であり、アプリケーションまたはスキーマがそれをブール値として解釈するかどうかを決定します。

JSON と XML の比較表

スキーマと検証の選択

パーサーはペイロードがフォーマット文法に従っていることを証明するだけです。合計金額が非負であること、国コードが承認されたセットに属すること、または必須の識別子が存在することを証明するものではありません。それらは契約ルールです。

JSONスキーマは必須プロパティ、許可された型、数値境界、文字列パターン、配列制約、および再利用可能なサブスキーマを定義できます。これは、APIプロデューサーと消費者がすでにJSON値で考えているときにうまく機能します。スキーマはオプションフィールドを文書化し、未知のプロパティが受け入れられるかどうかを制御することもできます。これはAPIの進化において重要です。

XMLスキーマ定義は、要素の順序、属性、単純および複雑な型、発生制限、ネームスペース対応構造を定義できます。RELAX NGは別の文法指向のアプローチを提供し、Schematronはドキュメント内の関係に依存する主張を表現できます。XMLプロジェクトは、すべてのルールを1つのスキーマ言語に強制するのではなく、構造検証とビジネスルール検証を組み合わせることがよくあります。

両方のエコシステムはバージョン管理の規律が必要です。オプションフィールドや要素を追加することは、既存のものの名前を変更するよりも通常、消費者にとって簡単です。プロデューサーは、未知のメンバーまたは要素が無視、保持、または拒否されるべきかを文書化する必要があります。消費者は、契約がクローズドワールド検証を要求しない限り、すべての認識できない追加を致命的と見なすことを避けるべきです。

重要なセキュリティの違い

JSONパーサーは特徴的な面積が小さくなっていますが、JSON入力は依然としてサイズ制限、ネスト制限、数値の境界、スキーマチェックを必要とします。深くネストされた値は、メモリまたはスタックスペースを消費する可能性があります。重複したオブジェクト名も、ライブラリが最初の値を保持するか、最後の値を保持するか、またはすべての出現を公開するかによって、一貫性のない動作を引き起こす可能性があります。

XMLパーサーは、外部エンティティや文書型宣言のような機能が意図しないファイル読み込み、ネットワークアクセス、またはリソース消費を引き起こす可能性があるため、明示的なハードニングが必要です。 OWASP XML外部エンティティ防止ガイダンス アプリケーションに必要のない危険なパーサー機能を無効にすることを推奨しています。安全なデフォルトはパーサーやバージョンによって異なるため、アプリケーションは展開する正確なライブラリを設定し、テストする必要があります。

フォーマットの選択は、承認や出力エンコーディングを置き換えるものではありません。正当なJSONまたはXMLペイロードには、信頼できない文字列が含まれる可能性があります。アプリケーションはドメイン値を検証し、HTML、SQL、シェルコマンド、ファイルパス、またはログに配置する際にデータを正しくエンコードする必要があります。

パフォーマンス、サイズ、およびストリーミング

JSONは、プロパティ名がメンバーごとに1回しか表示されず、終了タグがないため、レコード型データに対して通常、バイト数が少なくて済みます。XMLは、開始タグと終了タグで要素名を繰り返すことがあります。その観察は便利ですが、普遍的なベンチマークではありません。圧縮は重複した名前のオーバーヘッドを取り除き、属性を使用したXML表現は、非常にネストされた要素設計よりもJSONに近い場合があります。

パーサーの速度は、ライブラリ、言語、検証設定、メモリアロケーション、およびデータ形状に依存します。ストリーミングXMLパーサーは、フルなメモリツリーを構築することなく大きな文書を処理できます。JSONライブラリは、イベントベースまたはインクリメンタルパースもサポートしていますが、多くのアプリケーションの例では最初にフルバリューをロードします。正しいベンチマークは、プロダクションで使用される正確なペイロード、パーサー、スキーマチェック、圧縮、下流の変換を測定します。

XMLにはSAXやプルパーサーなどの明示的なストリーミングAPIがあります。連結されたJSON値は曖昧であるため、JSONストリームにはフレーミングルールが必要です。システムは通常、レコードを配列にラップしたり、長さの接頭辞を使用したり、各レコードが1つの物理的な行に留まることができるときに改行区切りのJSONを採用したりします。

各フォーマットの適合場所

JSONとXMLの選択方法

ペイロードが自然にオブジェクトグラフであり、主要な消費者がアプリケーションコードであり、簡潔なウェブトランスポートが重要な場合にはJSONを選択します。チームが小さな文法とフロントエンドおよびバックエンドツール全体での広範なサポートを望む場合も、JSONは良いデフォルトです。

ペイロードがレコードではなくドキュメントであり、複数の語彙にネームスペースが必要であり、混合コンテンツが発明されたマッピングなしで生き残らなければならない場合、あるいは確立されたパートナー契約がすでにXMLスキーマおよび変換に依存している場合はXMLを選択します。句読点を減らすためだけに成熟したXML契約をJSONに置き換えることは、価値よりも移行作業を増やす可能性があります。

どちらのオプションでもデータを表現できる場合、周囲のシステムを評価します：利用可能なバリデーター、デバッグツール、ストリーミングニーズ、パートナー要件、エラーレポーティング、および長期的なスキーマガバナンス。フォーマットは契約の一層です。命名規則、互換性ポリシー、セキュリティ制限、および所有権が、交換が信頼できるかどうかを決定します。

JSONとXMLの間の変換

機械的な変換は、制限されたサブセットに対してのみ明確です。JSONオブジェクトは、プロパティの子要素を持つXML要素にマッピングでき、配列は繰り返しの子要素にマッピングできます。逆のマッピングには、属性、繰り返し要素、名前空間、テキストノード、および空の要素に関するルールが必要です。これらのルールがないと、2つのコンバータが同じXMLから異なるJSONを生成する可能性があります。

インターフェース契約の一部としてマッピングを定義します。属性がプレフィックス付きプロパティになるか、一つの繰り返し要素がスカラーまたは単一アイテムの配列になるか、名前空間がどのように表現されるか、数値やブール値がどのように推測されるかを明示します。法律上または監査上の要件が正確な忠実性を要求する場合、元の文書を保持します。変換されたオブジェクトは、値を保持しつつ、コメント、プレフィックス、エンティティ参照、空白などの言語的詳細を失う場合があります。

結論

JSONとXMLは重複していますが、構造化テキストの交換可能なラベルではありません。JSONはアプリケーション開発者にAPIとソフトウェアオブジェクトに適合する簡潔な値モデルを提供します。XMLはドキュメントシステムに、混合コンテンツ、属性、名前空間、成熟したバリデーションおよび変換ツールを持つ豊かなノードモデルを提供します。実用的な選択はデータモデル、周囲のツール、および互換性の義務に従います—どのフォーマットが他のフォーマットを置き換えたという一般的な主張ではありません。