帯域幅を節約するために複数のHTTPリクエストをマージすることは良い考えですか？
低速のモバイル接続で時々使用される単一ページのアプリケーションを準備しています。その一部は、APIリクエストの点で非常に重い（新しい画面表示のために10の異なるリソースをフェッチする）。
さて、これらのサービスを必要なすべてのデータを提供するサービスにマージすることは良い考えですが、REST原則の観点からは「純粋」ではありませんか？予想される大幅なパフォーマンスの向上はありますか？
RESTの利点の1つは、従来のhttpキャッシュを介して要求をキャッシュできることです（これらがキャッシュ可能な要求であると仮定した場合）。
単一で、大きく、使用頻度が低く、おそらく異なるリクエストがある場合（私はアイテムをフェッチしますa,b,c,d今回とアイテムa,b,d,e次回）リクエストをキャッシュミスの可能性が高くし、自分とソースの間のどこかにある可能性のあるキャッシュから期限切れになる。
上記の2組のリクエストを考えると、2番目のリクエストは75％のキャッシュヒットレートを持ち、e 、4つすべてではなく。
キャッシュミスリクエストの最初のセットを実行する人はまだキャッシュミスを持っているため、これを使用している人にはすぐにわかるとは限らないことに注意してください。
これは、ローカル以外のキャッシュヒットが発生する可能性が低いモバイルネットワーク接続で理想的であると言っているのではありません。しかし、ホットスポットやその他のwifiの状況では、キャッシュヒットの方がはるかに便利です。
これの多くは、繰り返しになりますが、アプリケーションの動作方法によって異なります。起動時にこのすべてのデータを要求していますか？それとも、応答時間の予想が異なるページの読み込みについて話しているのでしょうか。
これをテストして、さまざまな状況でアプリケーションがどのように実行されるかを確認するのが理想的です。モバイルデバイスをローカルwifiネットワークにバインドした状況を設定することを検討してください 監視できます （これはGoogleへの最初のヒットです） 悪いインターネット接続のシミュレーション 物事が実際に機能する（または機能しない）方法と、どれが最高のパフォーマンスを発揮するかを確認します。
あなたの直感は幾分正しいです-概して、リクエストを少なくすることは確かに望ましいです。分厚いAPIの方が良い傾向があります。特に、接続が不安定で、一部の作業が見られ、一部は何にも依存できないため、悪夢のようなフォールバックシナリオの作成に失敗します。
大きな注意点が1つあります。かなり大きくなりすぎて、通話や応答が肥大化する可能性があります。たとえば、データが必要になるたびに大きなページの更新を強制するのではなく、最初にページをヒットしてから更新を小さなバイトでストリームインするときに、1つの大きな呼び出しを行うのが理にかなっています。
または、おそらく両方の方法でそれを実行する必要があります。
チェックしてください このDropbox Techブログ記事 。
そこでは、すべての写真のサムネイルを取得するために提案したソリューションを正確に実装した理由と方法について詳しく説明しています。彼らはそれが問題の価値があるかどうかを確認するためにパフォーマンスを測定していると言われるべきです、そしてそれは明らかにそれです。
短い要約：
Dropboxウェブサイトは何百ものサムネイルをロードする必要があります。一部のブラウザーの制限により、すべてのサムネイルが並行してロードされるわけではありません（要求はキューに入れられます）。 [〜＃〜] spdy [〜＃〜] を使用したかったのですが、システムの一部でまだサポートされていないため、使用できませんでした。最終的に、彼らはHTTP経由のバッチリクエストを使用しました。これは、応答ごとに複数のサムネイルを圧縮形式で返します。結果によると、全体のページ読み込み時間の改善は40％でした。
要するに：あなたのアプローチはやや正しく、ラッパーサービスの恩恵を受けることができます。
このサービスは、既存の単一の呼び出しを1つのサービス側メソッドに結合します。これを行うには、クライアントからサービス側への呼び出しを組み合わせ、おそらく現在までに行っているすべての単一のアトミックな安らかな呼び出しを利用します。
したがって、リクエストをキャッシュする機能として、RESTの恩恵を受け続けることになります。
ただし、最終的には、サービス/サーバーインフラストラクチャのパフォーマンスと、それを消費する必要のあるクライアント環境にすべて集約されます。