回答:
次のいずれかに該当する場合は、JSONよりもXMLを優先してください。
次のすべてが当てはまる場合は、JSONをXMLより優先します。
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
eval()大きなノーノーJSONをINGの？
XML対JSON relmで遭遇した他のいくつかのこと：
JSONはとても良いです
つまり、配列またはネストされた配列が好きになる傾向があります。ただし、JSONには両方がありません
したがって、2つ以上のJSONサービスを組み合わせると、名前空間の競合が発生する可能性があります。そうは言っても、私の経験でデータを交換するときにXMLを使用できるのと同じものの約90％でJSONを使用できます。
通常、JSONはよりコンパクトで、解析が高速です。
次の場合はXMLを優先します。
（ほぼ）XMLの重要なケースの1つ：生データを送信するよりも、HTMLスニペットを送信するほうが有益であることを検出しようとします。ああああは単純なアプリケーションで驚異的ですが、見過ごされがちです。通常、このスタイルは、サーバーが処理せずにWebページにインライン化されるHTMLスニペットを送信することを前提としています。
通常、AHAHの場合、CSSを最大限に活用してスニペットを視覚的にマッサージし、ユーザー固有またはアプリケーション固有の設定を使用してスニペットの関連部分を非表示/表示するなどの単純な条件を実装します。
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は、XML機能セットの上に効果的に構築され、Webサービスを記述する標準化された方法を提供します（例：タイプと操作）WSDLを介して。WSDL仕様の冗長性と複雑さは、開発に手間がかかる可能性があることを意味しますが、同時に、使用可能なツールが大幅に増え、最新のほとんどの言語は、いくつかの負担を負うクライアントプロキシを生成する自動化ツールを提供します外部サービスと相互運用する場合はオフにします。
頻繁に変更されることがない明確に定義された「エンタープライズサービス」がある場合、またはWebサービスに多くの異なる言語からアクセスする必要がある場合は、WebサービスにXMLを使用することをお勧めします。
そのすべての利点について、XMLには欠点もあります。型指定された拡張可能な形式を提供するために名前空間に依存し、同じドキュメント内の属性と要素を指定できるようにします。1つのドキュメント内に異なる名前空間があることは、Xmlパーサーを使用してデータを抽出するときに多くの時間を意味します。また、取得/トラバースする各要素の名前空間を提供する必要があります。また、ペイロードを外挿して、必要以上に冗長にします。要素だけでなく属性も出力するオプションがあると、クラスがXMLドキュメントに適切にマップされません。これらの機能だけでは、ほとんどの言語でプログラムに適合しないため、作業が面倒で面倒になります。
一方、JSONは非常に緩やかに型付けされており、基本型（数値、ブール、文字列、オブジェクト、配列）のみをサポートしているため、多くの点でXMLとは完全に逆です。他のすべては本質的に文字列に収まる必要があります。これは、言語の境界を越えて通信しようとする場合には適切ではありません。より具体的なタイプをサポートする場合は、帯域外の非標準仕様に準拠する必要があるためです。利点として、その限られた機能セットは、ほとんどの言語にプログラムで適切に適合し、JSON文字列を直接JavaScriptオブジェクトに評価できるため、JavaScriptに完全に適しています。
サイズとパフォーマンス
私はいくつか持っている利用できるのNorthwindデータベースのベンチマーク MicrosoftのXMLとJSON実装間のサイズと速度を比較します。基本的に、XMLはJSONのサイズの2倍を超えますが、JSONのものより30％以上高速であるため、MicrosoftがXML DataContractSerializerを最適化するために多くの努力を払ったように見えます。サイズとパフォーマンスの間でトレードオフを行う必要があるようです。この事実に満足していないので、私は自分の高速JsonSerializerを作成することにしました。これは、MSのXMLの2.6倍になり、両方の世界で最高です:)。
JSONルートをたどると、XMLが10年前に直面したのと同じ問題に遭遇します。
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の使用
XMLの使用
私が見つかりました。デジタルバザーでこの記事は本当に面白いです。
記事の一部を以下に引用します。
JSONプロについて：
渡したいものがすべてアトミック値、リスト、またはアトミック値のハッシュである場合、JSONにはXMLの多くの利点があります。インターネット上で簡単に使用でき、さまざまなアプリケーションをサポートし、JSONを処理するプログラムを簡単に作成できます。オプションの機能はほとんどなく、人間が判読可能でかなり明確であり、そのデザインは正式で簡潔であり、JSONドキュメントは簡単に作成でき、Unicodeを使用しています。...
XMLプロについて：
XMLは、構造化されていないデータの豊富さを非常にうまく処理します。XMLの死がWeb APIデザイナーの幹部によって喜んで祝われたとしても、XMLの将来についてはまったく心配していません。
そして、私は「あなたにそう言った！」私の机にトークンを置きます。より豊かなAPIを開発するように求められたときに、JSONの人々が何をするかを楽しみにしています。あまり構造化されていないデータを交換したい場合、JSONに変換しますか？JSONのスキーマ言語についての言及がときどき見られますが、他の言語もフォローしますか？...
クイックルール：
説明：
JSONの唯一の役割は、ほとんどのプログラミング言語に共通のデータ型（リスト、ハッシュ、スカラー）を使用してオブジェクト指向のデータをシリアル化することです。そのため、これを打ち負かしたり改善したりすることはできません。つまり、「JSONにはバージョン番号がないため、JSON文法の改訂は想定されていません」。- ダグラス・クロックフォード（あなたが完全にあなたの仕事をしているという印としてそれを打ち負かすことはできません）
XMLはかつてデータ交換形式として販売されていましたが、最も一般的な2つのユースケースを検討してください：非同期クライアント/サーバー通信（AJAX） -JSONはXMLを完全にほとんど置き換えました（Xは実際にはJである必要があります）：JSONはXMLを冗長な代替手段にしています。
XMLが広く使用されているもう1つのことは、プログラム用の人間が書き込み/読み取り可能な（？）データファイルでしたが、ここでも、YAMLでより簡潔で、プログラムに優しく、より人間に優しい形式であるJSONスーパーセットがあります。
したがって、データ表現については、JSONはXMLを全面的に上回っています。XMLには何が残っていますか？混合コンテンツのドキュメント表現。それが意図されていたものです。