サーバーでXMLを解析するか、プロキシを提供して、ブラウザで解析する必要がありますか？

サードパーティのAPIとのインターフェースが必要です。このAPIを使用して、エンドユーザーのブラウザー内からGET要求を作成し、XML応答を受信します。このデータは、ユーザーがデータを検索したり、決定に使用したりできるブラウザーベースのアプリケーションで使用されます。主な問題は、ほとんどのブラウザーがクロスドメインXMLの使用を制限しているため、単純に取得できないことです。 APIからのXML。

ただし、全体的なデータは基本的に2つのセットに分かれています。

1. 最初のデータセットは公開されており、頻繁に更新する必要があるだけなので、サーバー側のすべてのユーザーがキャッシュできるため、トラフィックが大幅に軽減されます。
2. 2番目のデータセットはプライベートであり、各ユーザーに個別です。このデータは、APIでもより頻繁に更新されます。これにより、キャッシュの効果が大幅に低下します。

スケーラビリティの理由から、サーバーの負荷をできるだけ小さくしたいと思います。

私の前に2つのオプションが表示されます。

1. XMLリクエストをサードパーティのサーバーにルーティングし、クライアントとサードパーティのAPIの間で直接やり取りするために使用できるプロキシを提供します。
2. サーバーにXMLからJSONへの変換を実行させ、不要な情報を削除します。これは基本的に、サーバー用の新しいAPIを作成することを意味します。これは、サードパーティAPIからのリクエストに変換されます

ユーザーにデータを提供するための最良の方法は何ですか？（2つのオプションのいずれかである必要はありません）

プロキシオプションは、実装が最も簡単なオプションです。カスタム開発を行う必要はありません。プロキシをセットアップするだけです。これも簡単です。維持する必要のある追加のコードはありません。APIが変更された場合、ユーザー側で行う変更はありません。

プロキシが推奨されます：

• 稼働中のソフトウェアを迅速に出荷する必要がある場合。これは、たとえば、機能を出荷しようとしていて、プロジェクトの実装フェーズ中にクロスドメインのAJAXリクエストを作成できないことが判明した場合に、これは良い選択になります。

• または、現在のAPIが適切に設計されている場合：アーキテクチャは良好で、呼び出しは非常に明確で、ドキュメントは完全で理解しやすいものです。

• または、現在のAPIが変更される可能性がある場合。変更する場合は、JavaScript実装を変更するだけです。プロキシの代わりに、結果を解析して独自のJSONを生成する場合、APIを変更するとサーバー側コードの変更が必要になるリスクがあります。

一方、結果を解析すると、クライアント側でAPIを完全に抽象化できるという利点があります。新しいインターフェースを設計する必要があるため（元のAPIが適切に設計されていない場合）、抽出、変換、およびロード機能を実装する必要があるため、これは低速の代替手段ですが、大規模なプロジェクトでは長期的な選択肢として適しています。これは推奨される選択です。

• 追加機能が必要な場合。通常のプロキシサーバーでサポートされていないレベルでのキャッシュ、暗号化、別の認証モデルなど、元のAPIでは利用できなかったさまざまな機能を利用できます。

  たとえば、AJAX要求の数が問題になる場合や、双方向通信モデルが理にかなっている場合は、Webソケットを実装できます。

• または、現在のAPIが適切に設計されていない場合。ファサードパターンと同様に、このアプローチではAPIを再設計できます。元のAPIが貧弱な場合、ファサードを持つことで、レガシーAPIの元の作成者が行った設計上の悪い選択を解決できます。APIの全体的なアーキテクチャなどの大きな部分だけでなく、引数の名前やエラーメッセージなどの詳細にも対応できます。

  既存のAPIを変更することが不可能な場合もありますが、ファサードがあると、元の設計の欠点とエラーを抽象化したクリーンなコードで作業できるようになります。

• または、現在のAPIが変更される可能性がある場合。実際、APIが時間とともに変化する場合は、ファサードのパブリックインターフェイスに影響を与えずに、JavaScriptではなくサーバー側のコードを変更することをお勧めします。サーバー側のプログラミングの経験が豊富であるか、サーバー側のリファクタリング用のツールが豊富であるか、プロジェクトでサーバー側のコードのバージョン管理を処理するのが簡単なため、どちらかが簡単になる場合があります。

JSON、パフォーマンス、キャッシングなどの話を省略していることに気付くでしょう。その理由は以下のとおりです。

• JSONとXML：適切なテクノロジーを選択するかどうかは、あなた次第です。それには、JSONを介したXMLの過熱、データのシリアル化にかかる時間、および解析の容易さを客観的に測定します。

• パフォーマンス：さまざまな実装をベンチマークし、最速のものを選択して、プロファイリングし、プロファイラーの結果に基づいて最適化します。非機能要件で指定されたパフォーマンスを達成したら停止します。

  また、何を達成しようとしているのかを理解してください。相互に作用し合う部分がいくつかあります。元のAPI、サーバーとAPIの間の帯域幅、サーバーのパフォーマンス、サーバーとエンドユーザー間の帯域幅、およびそれらのマシンのパフォーマンスです。30ミリ秒以内にリクエストへの応答を取得するように求められたが、元のAPIは40ミリ秒を費やした場合。リクエストを処理すると、何をしても、必要なパフォーマンスを得ることができなくなります。

• キャッシング：キャッシングは、Webアプリケーションの速度を上げたり、帯域幅を減らしたりするための手法の1つです。

  1. 多くの場合、HTTPヘッダーを適切に設定するのは難しいので、クライアントキャッシングも使用するようにしてください（サーバー側のキャッシングによって、ユーザーと顧客の間の帯域幅の使用量が減ることはありません）。

  2. キャッシュする内容、キャッシュを無効にする期間と時期を正しく決定していることを確認してください。製品の説明が10秒前に変更されても、eコマースWebサイトの顧客が古いバージョンを表示している場合は問題ありません。所有者が説明を変更して送信し、キャッシュのために以前のバリアントが引き続き表示される場合、これは問題があります。

  3. キャッシングだけに焦点を当てないでください。たとえば、縮小も重要です。リクエストの数を減らすことも有益です。

ある第三：あなたが見ていない可能性がありますオプションのクロスオリジンリソース共有（CORS）が。

CORS標準は、サーバーが許可されたオリジンドメインにリソースを提供できるようにする新しいHTTPヘッダーを追加することで機能します。ブラウザはこれらのヘッダーをサポートし、それらが確立する制限を尊重します。

例：サイトがhttp://my-cool-site.comであり、ドメインhttp://third-party-site.comにサードパーティAPIがあり、AJAX経由でアクセスできるとします。

そして、my-cool-site.comからサーバーが提供するページが、third-party-site.comにリクエストを出したと仮定します。通常、ユーザーのブラウザは、Same-Originセキュリティポリシーに従って、自分のドメイン/サブドメイン以外の他のサイトへのAJAX呼び出しを拒否します。ただし、ブラウザとサードパーティのサーバーがCORSをサポートしている場合、次のことが起こります。

• ブラウザは、次のHTTPヘッダーをthird-party-site.comに送信します

  Origin: http://my-cool-site.com

• サードパーティのサーバーがドメインからのリクエストを受け入れると、次のHTTPヘッダーで応答します。

  Access-Control-Allow-Origin: http://my-cool-site.com

• すべてのドメインを許可するために、サードパーティのサーバーはこのヘッダーを送信できます：

  Access-Control-Allow-Origin: *

• サイトが許可されていない場合、ブラウザはエラーをスローします。

クライアントにCORSをサポートするかなり最新のブラウザーがあり、サードパーティのサーバーもCORSをサポートしている場合は、コードを少し変更するだけで確実にCORSを使用できます。

CORSについてのわかりやすい説明を見つけました。その説明には、別の方法であるJSONPもあります。ただし、JSONPではコードにかなりの量の変更が必要になります。

CORSリクエストを行うにはXMLHttpRequest、Firefox 3.5以降、Safari 4以降、Chromeで使用しXDomainRequest、IE8 以降ではオブジェクトを使用します。XMLHttpRequestオブジェクトを使用しているときに、クロスドメインリクエストを実行しようとしていることがブラウザに認識されると、CORS動作がシームレスにトリガーされます。

次に、クロスブラウザーCORSオブジェクトの作成に役立つJavaScript関数を示します。

function createCORSRequest(method, url){
    var xhr = new XMLHttpRequest();
    if ("withCredentials" in xhr){
        // XHR has 'withCredentials' property only if it supports CORS
        xhr.open(method, url, true);
    } else if (typeof XDomainRequest != "undefined"){ // if IE use XDR
        xhr = new XDomainRequest();
        xhr.open(method, url);
    } else {
        xhr = null;
    }
    return xhr;
}

「ほとんどのブラウザがクロスドメインXMLの使用を制限している」とのことですので、サードパーティのサーバーがCORSをサポートしていない可能性があります。次に、代替アプローチを見つける必要があります。

スケーラビリティの理由から、サーバーの負荷をできるだけ小さくしたい

これは多かれ少なかれ答えを示していると思います。前処理されたデータをクライアントに提供するかどうかは、主に次の要素に依存します。

1. トラフィックに関する違い
2. 処理のパフォーマンスへの影響
3. 異なるデータ形式がクライアントに与える影響

XMLが比較的小さい場合、または要求がわずかしかない場合は、XMLをクライアントに転送して、それを忘れるだけで十分です。前処理されたデータがまだ元のデータの大部分である場合、またはクライアントが別のデータ形式（たとえば、JSONなど）から大きな利益を得られない場合も同様です。

ただし、クライアントが大きなXMLデータセットの処理に苦労している場合、またはクライアントが元のXMLデータのほんの一部しか必要としない場合は、サーバー側でいくつかの前処理を行うことは理にかなっています。

結局のところ、サーバーをスケーリングする方が、クライアント/ブラウザーや利用可能な帯域幅をスケーリングするよりも簡単です。それを1文にまとめるには、ボトルネックがシステムのどこにあるかによって異なります。

私の選択は、キャッシュして圧縮（不要な情報を破棄）し、結果をクライアントブラウザーにgzipすることです（オプション＃2）。ブラウザーは通常ハイエンドのCPUではなく、サーバーからブラウザーへのネットワーク回線の容量は限られているためです。私はモバイルクライアントについて話している。モバイルクライアントをサポートする予定がない場合は、よりシンプルなものを選択してください。Google:CORS proxy