web-dev-qa-db-ja.com

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

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

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

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

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

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

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

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

javascriptapixmlwebsitesjson
11
amethystdragon

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

プロキシは好ましい選択です：

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

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

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

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

  • 追加の機能が必要な場合cachingなど、元のAPIで利用できなかったさまざまな機能を通常のプロキシでサポートされていないレベルで利用できますserver、またはencryption、または別のauthenticationモデル。

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

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

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

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

JSON、パフォーマンス、キャッシングなどの話を省略していることに気づいたかもしれません。その理由は次のとおりです。

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

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

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

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

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

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

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

12
Arseni Mourzenko

あなたが見たことがないかもしれないthirdオプションがあります： Cross Origin Resource Sharing（CORS） 。

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

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

そして、my-cool-site.comからサーバーが提供するページが、third-party-site.comにリクエストを出したと仮定します。通常、ユーザーのブラウザは拒否しますAJAX Same-Origin Security Policy に従って、自分のドメイン/サブドメイン以外の他のサイトへの呼び出し）==。ただし、ブラウザと3番目のパーティサーバーは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の素敵な説明 を見つけました。これには、これを行う別の方法もあります： [〜＃〜] jsonp [〜＃〜] 。ただし、JSONPではコードにかなりの量の変更が必要になります。

CORS要求を行うには、Firefox 3.5以降、Safari 4以降ではXMLHttpRequestを使用し、IE8 +ではChromeおよびXDomainRequestオブジェクトを使用します。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をサポートしていない可能性があります。次に、代替アプローチを見つける必要があります。

7
sampathsris

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

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

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

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

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

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

4
JensG

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

0
xmojmr