私は最近、データの送受信のために Restful Web サービスに接続する iOS アプリを含むプロジェクトを引き継ぎましたが、サーバーのパフォーマンスに苦労していることに気づきました。
RESTful であるため、さまざまな URI エンドポイントからさまざまな種類のデータにアクセスできます。ユーザーがアプリに初めてログインするとき (登録部分は無視してください)、クライアントはそのユーザーのすべてのデータをダウンロードする必要があります。データは異なるエンドポイントに存在するため、クライアントはそれぞれにリクエストを送信し、同じサーバーに多くのリクエストを送信してすべてのデータを取得します。
私の質問...これは健全なアーキテクチャですか? サーバーは、1 人のユーザーのデータを取得するためだけに多くの要求を処理することになります。ユーザーのすべてのデータを返す単一のリクエストを作成する方が賢明ではないでしょうか? サーバーは appengine で、無料の割り当てをより効率的に使用しようとしています。
事前に洞察をありがとう！
データがどのように構造化されているかを知らずに答えることは困難です。
これらの 6 ～ 7 回のリクエストで同じエンティティを再クエリしている場合、それは悪い考えです。異なるエンティティをクエリしている場合、それを 1 つのクエリに結合しても大きな違いはありません。
複数のリクエストがあると、ユーザーが結果を受け取るとページが更新されるのを見て、UI の応答性が向上したと「感じる」こともできます。単一のリクエストでは、ユーザーはリクエスト全体が完了するまで待機するだけです。
プロジェクトを作成した人は誰でも、最初にさまざまなタイプのオブジェクトの要求を分離することによって、REST API のクリーンさを採用することに決めたようです。すべてのユーザー関連オブジェクトを 1 つの要求に統合したい場合、それはおそらくはるかに「厄介な」アーキテクチャです。
複数のリクエストを行うことによるオーバーヘッドは確かにありますが、一般的にはそれほど大きな問題ではありません。
リクエストの制限時間は 60 秒です。単一の「return-all-user-data」リクエストに対して実行する必要がある作業によっては、これが役割を果たす場合があります。
Google App Engine のドキュメントを確認してください:
https://developers.google.com/appengine/docs/java/runtime#The_Request_Timer