多くの非同期呼び出しとAPIの単一呼び出し

特に、JavaScriptを介してHTML5フロントエンドで使用されるREST APIを開発しています。このアプリケーションは組織内で使用するためのもので、通常は約300人のユーザーがいますが、1000ユーザー程度までスケールアップしたいと考えています。

通常、APIへの接続はLAN内で行われるため、接続の品質と遅延は良好になりますが、3G / 4Gを介した接続が遅く、遅延が発生する可能性のあるインターネットでの時折の使用は除外されません。

私たちが考えた2つのオプションは次のとおりです。

1. フロントエンドは、APIに対して複数の非同期呼び出しを同時に行い、インターフェイスのさまざまなコンポーネントをロードします。

   • 長所：シンプル。
   • 短所：サーバーへの接続が増えます。

2. フロントエンドのコントローラーは、オブジェクトを取得する必要があるパラメーターとして渡すAPIを1回呼び出します。

   • 長所：サーバーへの接続は1つだけですが、サーバーはデータベースに複数の接続を作成します。
   • 短所：フロントエンドとAPIの両方のメカニズムが必要です。設計が複雑になります。

詳細な説明：さまざまなリソース... / Product ... / Locationsなどがあります。これらのリソースは単独で取得できますが、別の抽象的なリソース... / screen？Product＆Locationsが1回の呼び出しで両方を取得します。

オプション1（複数の非同期呼び出し）が最良の選択です：

1. 個々の呼び出しはそれぞれ独自のエンティティであるため、何かが失敗した場合は個別に再試行できます。モノリシックな「ワンコール」アーキテクチャでは、1つのことが失敗した場合、もう一度コール全体を実行する必要があります
2. サーバー側のコードはよりシンプルになります。やはりモジュール性です。つまり、さまざまな開発者がさまざまなAPIリソースで作業できます。
3. 典型的なMVCパターンでは、1つのAPI呼び出しで複数の個別のリソースをロードすることは意味がありません。たとえば、/productsページに表示する製品のリストを取得するリクエストを行い、人気のある製品が販売されている場所のリストも表示する場合、2つの別個のリソースがProductありLocationます。同じページに表示されますが、論理的に呼び出したり/products、場所を返すこともできません
4. ロギング/使用率レポートは、モジュラーアプローチでよりシンプルになります。にリクエストを行い、/products場所もロードしている場合、ログファイルは非常に紛らわしくなります。
5. 特定のリソースに問題がある場合、ワンコールアプローチではページ全体が破損し、ユーザーに何が壊れたのかがわかりません。これは、チームが問題を修正するのに時間がかかることを意味します。ただし、モジュール式のアプローチでは、何かが壊れた場合、何が壊れたのかが非常に明確になり、より迅速に修正できます。また、ページの残りの部分を台無しにしません（物事が密接に結合されていない限り...）
6. 物事が分離されている場合、一般に変更を行うのが簡単になります。1つのAPI呼び出しで5つのリソースがロードされている場合、何かを変更したいときに物事を壊さないようにする方法を見つけるのは困難です

全体のポイントは、リソースが分離されていることであり、REST APIでは、「サーバーへの接続を保存している」場合でも、単一のAPIパスから多くの別個のリソースを返すことは意味がありません。ところで、条件付きで（異なる）リソースを読み込むためにパラメーターを使用することはRESTfulではありません。

とは言っても、唯一の論理的なオプションは、リソースを分離するために複数の非同期要求を行うことです。モジュラーアプローチを採用してください。

PS-HTTP接続のオーバーヘッドが信じられないほど低く、LAN上にいる場合は特に、「サーバーへの接続」を早めに最適化しないでください。簡単な設計をすぐに選択するのではなく、この種の考え方は、後で問題を引き起こす可能性があります。