レストデザイン-複数の呼び出しと1つの呼び出しですべてのデータを返す

AndroidアプリのREST APIを構築しようとしています。私が持っていると仮定usersして、テーブル(id, name, email)とsongsを持つテーブルを(id, song_name, album)、豊富なとして、それらの間の関連を参加しstreamsました(user_id, song_id, listen_count)。すべてのストリームの詳細を取得して、アプリにリストとして表示したい。リストには、曲名、アルバム名、ユーザー名、聴取数が表示されます。私は3つのもっともらしいオプションを見ます-

1. GET/streamsすべてのリストフェッチsong_idsとをuser_ids。次に作るGETに/user/:idして/song/:id、ユーザーと曲の情報を取得するために、各ユーザと楽曲IDのために。
2. GET/streamsすべてのリストフェッチuser_idsとをsong_ids。次に、すべてのユーザーに関する情報を取得GETする/user?ids=<comma_separated_ids>ために1つ、すべての曲に関する情報を取得するGETためsong?ids=<comma_separated_ids>に1つ。

3. GET/streams1回の呼び出しですべてを取得します。何かのようなもの -

   [
   
     {
   
       "user_id" : 10,
       "song_id" : 14,
       "listen_count" : 5,
       "user" : {
         "id"     : 10,
         "name"   : "bla", 
         "email"  : "bla",
       },
       "song" : {
         "id"     : 14,
         "name"   : "blu",
         "album"  : "blu"
      }
     },
   ...
   ]
   

オプション3で一回の呼び出しですべてが得られるので、私は誘惑に駆られます。しかし、それは非常に休むことはないと思いますし、スケーラブルではないのではないかと心配しています。オプション2は適切ですが、3回の呼び出しが必要であるため、リストのロードにかなりの時間がかかります。オプション1は残りの部分に従いますが、リストを表示するために多くの呼び出しが必要になるため、モバイルデバイスからの多くの呼び出しは実行できません。

これに対処するために推奨される方法は何ですか？

RESTインターフェースを作成する場合、RESTインターフェースの応答がデータベースのテーブルまたは結合に直接対応するという要件はなく、期待もされません。

あなたの/streamsインターフェースは、

[
  {
    "listen_count" : 5,
    "user" : {
      "href"     : "/users/10",
      "name"   : "bla", 
    },
    "song" : {
      "href"     : "/songs/14",
      "name"   : "blu",
      "album"  : "blu"
    }
  },
  ...
]

JSONオブジェクトには、ストリームリソースのコンシューマーに（ほぼ）常に関連するユーザーと曲の主な詳細、および詳細が必要な場合は関連するユーザー/曲リソースへのリンクが含まれます。

これは基本的に3番目のオプションのバリエーションであり、詳細が必要な場合はオプション1にフォールバックします。

間違いなく、不透明なIDに加えて、各曲とユーザーに関するメタデータGETを返す単一のオペレーションが必要です。

• あなたが指摘したように、それははるかに簡単です。それは良いことです。
• あなたのクライアントのための最も一般的な操作の1を作ることである代わりにO（n）の要求の単一のサーバー要求をアプリずっとよりスケーラブル。長期的には、ネットワークが最大のボトルネックになるため、必要以上のリクエストを送信する必要はありません。
• 追加のREST呼び出しを行うことを除いて、ID自体は少し役に立たない。
• メタデータが比較的小さく、制限されたサイズである限り（たとえば、説明テキストのページや実際のオーディオファイルはなく、名前、タイプ、カウントなど）、IDに加えてメタデータを返すことは、パフォーマンスの問題になる可能性は低いです。