これらのいずれかに該当する場合は、JSONよりもXMLを優先してください。
- メッセージの検証が必要です
- XSLTを使用しています
- あなたのメッセージには多くのマークアップされたテキストが含まれています
- JSONをサポートしない環境と相互運用する必要があります
これらがすべて当てはまる場合は、XMLよりもJSONを優先してください。
- メッセージを検証する必要はありません。または、逆シリアル化の検証は簡単です
- メッセージを変換していません。または、逆シリアル化を変換するのは簡単です
- メッセージはほとんどデータであり、マークアップされたテキストではありません
- メッセージングエンドポイントには優れたJSONツールがあります
XMLを使用する必要がない限り、JSONを使用します。理解するのがより簡単で、（構成のオーバーヘッドが少ないため）コンテキストでライブラリを使用できる場合、読み取りおよび書き込みのプログラムが簡単になり、それらは今やどこにでもあります。
Amazonが最初にカタログをWebサービスとして公開したとき、JSONとXMLの両方を提供していました。実装者の90％がJSONを選択しました。
クライアント側ですでにJavaScriptを実行している特定のケースを考えると、次の理由からJSONを使用します。
JSONはJavaScriptにネイティブであるため、クライアント側で記述するコードを少なくする必要があります-JSON文字列を
eval()（または、さらに良いことにJSON.parse()）して、オブジェクトを取得するだけです。つかいます。同時に、クライアント側でJSONを評価する方が効率的であるため、高速になります。
JSONシリアル化は、XMLよりも短い文字列を生成します。 JSONを使用すると、ネットワーク上で実行されるデータの量が減り、その点でパフォーマンスが向上します。
さらに詳しい資料は次のとおりです。 http://www.subbu.org/blog/2006/08/json-vs-xml
XMLとJSONの関係で私が遭遇した他のいくつかのこと：
JSONは
- 名前/値のペア
- それらのペアをネストする
つまり、配列またはネストされた配列を好む傾向があります。ただし、JSONには両方がありません
- 属性
- 名前空間
したがって、2つ以上のJSONサービスを組み合わせると、名前空間の競合が発生する可能性があります。 JSONは、私の経験でデータを交換するときにXMLを使用できるのと同じことの約90％に使用できると言われています。
通常、JSONはよりコンパクトで、解析が高速です。
次の場合はXMLを優先します：
- クライアントでデータを処理する必要があり、そのためにXSLを活用できます。 XML + XSLチェーンは、特に大きなデータチャンクの場合、JSON + JavaScriptよりも高速に動作する可能性があります。
- 1つの良いケースは、データをHTMLスニペットに変換することです。
- さまざまなレガシーケース：
- 既存のXMLサービスがあり、何らかの理由でJSONで書き直すのは面倒です。
- ユーザーの入力を使用した軽い処理の後、このデータをXMLとしてポストバックする必要があります。
（ほぼ）XMLの重要なケースの1つ：生データを送信するよりもHTMLスニペットを送信する方が有益な場合を検出しようとします。 [〜＃〜] ahah [〜＃〜] は、単純なアプリケーションで驚くべきことをすることができますが、見落とされがちです。通常、このスタイルは、サーバーが処理せずにWebページにインライン化されるHTMLスニペットを送信することを前提としています。
通常、AHAHの場合、CSSを最大限に活用してスニペットを視覚的にマッサージし、ユーザー固有またはアプリケーション固有の設定を使用してスニペットの関連部分を非表示/表示するなどの単純な条件を実装します。
JSONは、データを解析するためにクライアントブラウザーが行う必要がある処理の観点から、常に望ましいものです。また、JSONは軽量のデータ交換形式です。
XML解析は常に多くのブラウザリソースを消費するため、特に必要な場合を除き、できる限り避ける必要があります。
JSONは解析が簡単で高速です。 XMLは解析が少し難しく、解析と転送が遅くなります（ほとんどの場合）。
JQueryを使用しているため、JSONを使用することをお勧めします。jQueryはJSONデータを取得し、それを自動的にJavascriptオブジェクトに変換できます。実際、 evalを使用してJSONデータをJavascriptオブジェクトに変換 できます。 XMLは、手動で横断する必要があります（これがJavascriptでどのように機能するかはわかりませんが、XMLライブラリを使用したほとんどの言語では困難/厄介です）。
Webプロトコルの履歴（SOAP、XML、JSON、REST、POXなど）の詳細についてのブログ投稿があり、それぞれの長所と短所をまとめています。 http：// www .servicestack.net/mythz_blog /？p = 154
実際、動的（JSON）言語と静的（XML）言語の違いを比較することで、XMLとJSONの多くの類似点を引き出すことができると思います。
基本的に、XMLは、より厳密で厳密なシリアル化形式であり、オプションで付随するスキーマ（XSDまたはDTD）で検証できます。 XSDは非常に複雑で、多くの異なるタイプを記述することができます。日付、時刻、列挙、ユーザー定義型、さらには型継承など。SOAPは、Webサービスを記述する標準化された方法を提供するXML機能セットの上に効果的に構築されます（例：型と操作）WSDLを介して.WSDL仕様の冗長性と複雑さは、開発に手間がかかる可能性があることを意味しますが、同時に、より多くのツールが利用可能であり、ほとんどの現代言語は、クライアントプロキシを生成する自動ツールを提供します外部サービスとの相互運用を試みる際の負担の一部（同時に、頻繁に変化するWebサービスを処理する場合、生成されたプロキシ自体が負担になることがわかります）。
頻繁に変更されることのない明確に定義された「エンタープライズサービス」がある場合、またはWebサービスに多くの異なる言語からアクセスする必要がある場合は、WebサービスにXMLを使用することをお勧めします。
XMLにはすべての利点がありますが、XMLには欠点もあります。型指定された拡張可能な形式を提供するために名前空間に依存し、同じドキュメント内で属性と要素を指定できるようにします。 1つのドキュメント内で異なる名前空間を使用すると、Xml Parserを使用してデータを抽出するときに多くの時間を要することになり、取得/トラバースする各要素の名前空間も指定する必要があります。また、ペイロードを外挿して、必要以上に冗長にします。要素だけでなく属性も出力するオプションがあると、クラスがXMLドキュメントにうまくマッピングされません。これらの機能だけでは、ほとんどの言語にプログラム上の適合性が乏しく、作業が面倒で面倒です。 Microsoftは、XML属性を廃止し、クラスのプロパティをXml要素のみにマップすることにより、DataContractシリアライザーでこれをある程度認識し、単純化しました。
一方、JSONは非常に緩やかに型付けされており、基本型（Number、Bool、string、Objects、Arrays）のみをサポートしているため、多くの点でXMLとはまったく反対です。他のすべては基本的に文字列に収まらなければなりません。これは、言語の境界を越えて通信しようとする場合、あまり具体的ではありません。より具体的なタイプをサポートする場合は、帯域外の非標準仕様に従う必要があるからです。逆に、その限られた機能セットは、ほとんどの言語にプログラム的に適合し、JSON文字列はeval'ed JavaScriptオブジェクトに直接。
サイズとパフォーマンス
northwindデータベースベンチマークが利用可能 MicrosoftのXML実装とJSON実装のサイズと速度を比較しています。基本的にXMLはJSONの2倍以上のサイズですが、同時にMicrosoftがJSON DataContractSerializerの最適化に多大な努力を注いだように見えます。サイズとパフォーマンスをトレードオフする必要があるようです。この事実に満足せず、私は自分の高速 JsonSerializer を書くことにしました。これは、MSのXMLの2.6倍になりました。
XMLがXSDを介してネイティブにサポートしているため、着信データのチャンクを検証する必要がある場合は、JSONではなくXMLを選択します。
JSONルートをたどると、10年前にXMLが直面したのと同じ問題に直面します。
2つの異なるソースからのデータを1つのJSONパケットに混合すると、要素ラベルが互いにぶつかる可能性があります。梱包票と請求書を混同すると、突然、差出人アドレスはまったく異なるものを意味する場合があります。 XMLが名前空間を持っているのはそのためです。
異なるJSON構造間で変換するには、ありふれたコードを書く必要があります。データをマップするためのより宣言的な方法は、仕事を簡単にします。 XMLが[〜＃〜] xslt [〜＃〜]を持っている理由です。
JSONパケットの構造（フィールド、データ型など）を記述することは、人々がサービスに接続するために必要です。これにはメタデータ言語が不可欠です。 XMLにスキーマがある理由です。
2つの同時クライアント/サーバー会話を実行することに注意してください。サーバーに2つの質問をして、1つの回答が返された場合、どの質問に回答したかをどのように確認できますか？ XMLがWS-Correlationを持っている理由です。
http://json.org/xml.html の最初の行から
Extensible Markup Language（XML）は、Standard Generalized Markup Language（SGML）から派生したテキスト形式です。 SGMLと比較して、XMLは単純です。それに対して、ハイパーテキストマークアップ言語（HTML）はさらに単純です。それでも、HTMLに関する優れた参考書は1インチの厚さです。これは、ドキュメントのフォーマットと構造化が複雑なビジネスであるためです。 。 。 。
JSONは明らかに高速ですが、読みにくいことはさらに明確です。速度のためにJSONを使用し、人間の相互作用がある場合はXMLを使用し、速度を犠牲にすることができます。
JSONはjavascriptのネイティブエンコーディングです。作業がはるかに高速で簡単になります。
私は digital Bazaarのこの記事 本当に面白いと感じました。
記事の一部を以下に引用します。
JSONプロについて：
アトミック値またはアトミック値のリストまたはハッシュのみを渡す場合、JSONにはXMLの多くの利点があります。インターネット上で簡単に使用でき、さまざまなアプリケーションをサポートし、JSONを処理するプログラムを簡単に作成できます。オプション機能はほとんどなく、人間が判読可能で合理的に明確であり、その設計は形式的かつ簡潔であり、JSONドキュメントは簡単に作成でき、ユニコードを使用しています。 ...
XMLプロについて：
XMLは、非構造化データの完全な豊富さを非常にうまく処理します。 XMLの将来がWeb APIデザイナーの幹部によって喜んで祝われたとしても、XMLの将来についてはまったく心配していません。
そして、「そう言った！」トークンを私の机に置きます。より豊かなAPIの開発を求められたときにJSONの人々が何をするかを楽しみにしています。あまり構造化されていないデータを交換したい場合、JSONに変換しますか？ JSONのスキーマ言語について言及することがありますが、他の言語も従いますか？ ...
MicrosoftはXMLとJSONの両方をサポートしています。 XMLリテラルはVB 9.の新しいクールな機能でした。ASP.NET4.0の今後のバージョンでは、JSONはクライアント側テンプレートの力を活用するために必要です。
あなたが尋ねた質問から、jQueryの有無にかかわらずクライアント側で処理するのは簡単であるため、JSONがあなたにとって選択のようです。
JSONを使用する
- データがブラウザのJavaScriptによって消費される場合。
- データモデルは単純であり、複雑ではありません（複合オブジェクトが多すぎます）。
XMLを使用する
- ほとんどの場合、SOA異種プラットフォームおよびテクノロジー上の複数のサービスを統合する一種の環境で。
- SOAPには、HTTP以外の異なるプロトコルを介して送信できるという利点があります。
- XSLT、XSL-FOなどのデータモデル変換ツールで使いやすい.
- XMLデータを格納/クエリ（XQuery）するための多くのデータベースサポート。
- XMLは非常に成熟したデータ形式であるため、考えられるあらゆるユースケースをサポートするためのツールがたくさん見つかります。
クイックルール：
- JSON：プログラム間データ形式
- YAML（JSONスーパーセット）：人間からプログラムへのデータ形式
- XML：ドキュメントマークアップ形式
説明：
JSONの唯一の役割は、ほとんどのプログラミング言語に共通のデータ型を使用してオブジェクト指向データをシリアル化することです：lists、hashs 、およびスカラー、そしてその目的のために本当に打ち負かすことも改善することもできません。 「JSONにはバージョン番号がないため、JSON文法の改訂は予定されていません」。 - ダグラス・クロックフォード （あなたが完璧に仕事をしていることを示す印としてそれを打ち負かすことはできません）
XMLはデータ交換形式として販売されていましたが、最も一般的な2つのユースケースを検討してください：非同期クライアントサーバー通信（AJAX）-JSONはXMLはほぼ完全に置き換えられました（Xは実際にはJである必要があります）、およびWebサービス：JSONはXMLを冗長な代替手段にしました。
XMLが広く使用されたもう1つのことは、プログラム用の人間が書き込み可能/読み取り可能な（？）データファイルでしたが、ここでも、JSONスーパーセットであるYAMLのより簡潔で、プログラムに優しい、より人間に優しい形式があります。
そのため、データ表現に関しては、JSONはXMLを全面的に凌しています。では、XMLには何が残っていますか？混合コンテンツのドキュメント表現。これは、 意図されていた です。
JSONは、あらゆる種類の構成、データ交換、またはメッセージングに使用します。 XMLを使用するのは、他の理由で、またはドキュメントのようなデータを意味的にマークアップする必要がある場合のみです。
ほとんどの新しいWebテクノロジーはJSONを使用して動作するため、JSONを使用する正当な理由になります。大きな利点は、XMLでは同じ情報を複数の異なる方法で表現できることです。これはJSONではより簡単です。
また、JSON IMHOはXMLよりもはるかに明確であるため、明らかに有利です。 .NETを使用している場合、Json.NETはJSONの使用を支援する明確な勝者です。