Resto design - Várias chamadas vs retornando todos os dados em uma chamada

Estou tentando criar uma API de descanso para um aplicativo Android. Suponha que eu tenha uma userstabela com (id, name, email)e uma songstabela com (id, song_name, album)e uma associação de junção rica entre eles como streamstendo (user_id, song_id, listen_count). Quero buscar detalhes sobre todos os fluxos e mostrá-lo no aplicativo como uma lista. A lista mostraria o nome da música, o nome do álbum, o nome do usuário e a contagem de escutas. Eu vejo três opções plausíveis -

1. GETpara /streamse buscar uma lista de todos os song_idse user_ids. Em seguida, faça GETpara /user/:ide /song/:idpara cada usuário e ID da música para obter informações sobre o usuário e a música.
2. GETpara /streamse buscar uma lista de todos os user_idse song_ids. Então, um GETpara /user?ids=<comma_separated_ids>buscar informações sobre todos os usuários e um GETpara song?ids=<comma_separated_ids>buscar informações sobre todas as músicas.

3. GETpara /streamsbuscar tudo em uma chamada. Algo como -

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

Sinto-me tentado a optar pela opção 3 porque ela me dá tudo em uma ligação, mas não acho que seja muito tranquila e temo que não seja escalável. A opção 2 é boa, mas são necessárias três chamadas, o que significaria um tempo considerável para carregar a lista. E a opção 1 segue o resto, mas atenderá inúmeras chamadas para mostrar a lista e fazer tantas chamadas de um dispositivo móvel não é viável.

Qual seria a maneira recomendada de fazer isso?

Ao criar uma interface REST, não há nenhum requisito, ou mesmo expectativa, de que as respostas na interface REST correspondam diretamente às tabelas ou junções no banco de dados.

Sua /streamsinterface pode ser tão facilmente representada quanto

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

Onde os objetos JSON contêm os principais detalhes de usuários e músicas que são (quase) sempre relevantes para os consumidores de um recurso de fluxo e um link para os recursos relevantes de usuário / música, se mais detalhes forem necessários.

Essa é essencialmente uma variação da sua terceira opção, com um substituto para a opção 1, se mais detalhes forem necessários.

Você definitivamente deseja uma GEToperação única que retorne metadados sobre cada música e usuário, além de seus IDs opacos.

• Como você apontou, é muito mais simples. Isso é uma coisa boa.
• Tornar uma das operações mais comuns para seus aplicativos clientes uma solicitação de servidor único em vez de O (n) solicitações é muito mais escalável. A longo prazo, a rede será o seu maior gargalo, portanto, você não deseja enviar mais solicitações do que precisa.
• Os IDs por si só são meio inúteis, exceto para fazer chamadas REST adicionais.
• Contanto que seus metadados tenham um tamanho relativamente pequeno e limitado (por exemplo, nenhuma página de texto descritivo ou arquivos de áudio reais, apenas nomes, tipos, contagens etc.), devolvê-los além dos IDs provavelmente não será um problema de desempenho.