Rest design - Più chiamate e tutti i dati di ritorno in una chiamata

Naviga le tue risposte
7

Sto cercando di creare un'API di riposo per un'app per Android. Supponiamo di avere una tabella users con (id, name, email) e una tabella songs con (id, song_name, album) e un'associazione ricca di join tra di loro come streams con (user_id, song_id, listen_count) . Voglio recuperare i dettagli su tutti i flussi e mostrarli nell'app come elenco. L'elenco mostrerebbe il nome del brano, il nome dell'album, il nome utente e il numero di ascolti. Vedo tre opzioni plausibili -

  1. GET a /streams e recupera un elenco di tutti i song_ids e user_ids . Quindi imposta GET a /user/:id e /song/:id per ciascun utente e id canzone per ottenere le informazioni su utente e brano.
  2. GET a /streams e recupera un elenco di tutti i user_ids e song_ids . Quindi un GET a /user?ids=<comma_separated_ids> per recuperare informazioni su tutti gli utenti e un GET su song?ids=<comma_separated_ids> per recuperare informazioni su tutti i brani.

  3. GET a /streams e recupera tutto in un'unica chiamata. Qualcosa come - 

    [

  {

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

Sono tentato di optare per l'opzione 3 perché mi dà tutto in una sola chiamata, ma non penso che sia molto pieno e temo che non sia scalabile. L'opzione 2 è buona, ma ci vogliono 3 chiamate, il che significherebbe un tempo considerevole per caricare la lista. E l'opzione 1 segue il riposo, ma richiederà numerose chiamate per mostrare l'elenco e fare così tante chiamate da un dispositivo mobile non è fattibile.

Quale sarebbe la soluzione consigliata per questo?

    
posta aandis 28.08.2015 - 08:22
fonte

2 risposte

6

Quando si crea un'interfaccia REST, non vi è alcun obbligo, o addirittura aspettativa, che le risposte nell'interfaccia REST corrispondano direttamente alle tabelle o ai join nel database.

La tua interfaccia /streams può essere facilmente rappresentata come 

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

Dove gli oggetti JSON contengono i dettagli principali di utenti e canzoni che sono (quasi) sempre rilevanti per i consumatori di una risorsa di streaming e un link alle risorse utente / canzone pertinenti se sono necessari ulteriori dettagli.

Questa è essenzialmente una variante della terza opzione, con una ricaduta sull'opzione 1 se sono necessari ulteriori dettagli.

    
risposta data 28.08.2015 - 09:06
fonte
3

Sicuramente vuoi una singola operazione GET che restituisce metadati su ogni canzone e utente oltre ai loro id opachi.

  • Come hai sottolineato, è molto più semplice. Questa è una buona cosa.
  • Facendo una delle operazioni più comuni per le tue app client, una richiesta di singolo server invece di richieste O (n) è molto più scalabile. A lungo termine, la rete sarà il collo di bottiglia più grande, quindi non vuoi inviare più richieste di quelle necessarie.
  • Gli id da soli sono inutili, tranne che per effettuare ulteriori chiamate REST.
  • Finché i metadati hanno una dimensione relativamente piccola e limitata (ad esempio, nessuna pagina di testo descrittivo o file audio reali, solo nomi, tipi, conteggi e così via) è improbabile che restituirli in aggiunta agli id sia una performance problema.
risposta data 28.08.2015 - 09:00
fonte

Leggi altre domande sui tag

Perché usare plus + + = per la registrazione degli eventi? Come definire chiaramente i confini di un contesto limitato