È una buona idea che un'API restituisca solo gli ID dagli oggetti?

Question

È una buona idea che un'API restituisca solo gli ID dagli oggetti?

#1 da (2 voti)
#2 da (1 voti)

3

Ho questo URL:

  /api/pallets/list

Che restituisce un array JSON simile a questo:

 [{
     palletId: 333,
     code: 'J050000081',
     grower: {
         growerId: 35,
         name: 'Grower Of Blueberries Inc'
     },
     species: {
         speciesId: 1,
         name: 'Blueberries'
     },
     caliber: {
         caliberId: 5,
         name: '10-12'
     },
  }, ...]

I nomi sono spesso di grandi dimensioni e se l'elenco contiene 5000 pallet con molti nomi di byte.

Quando l'app client chiama api/pallets/list ha già scaricato l'elenco di coltivatori, specie e calibri, chiamando api/growers/list , api/species/list e api/calibers/list

Per questo motivo, mi chiedo se sia una buona idea che il server restituisca solo gli id delle cose, cioè:

 [{
     palletId: 333,
     code: 'J050000081',
     grower: {
         growerId: 35,
     },
     species: {
         speciesId: 1,
     },
     caliber: {
         caliberId: 5,
     },
  }, ...]

E poi l'app client avrà la responsabilità di completare il JSON, facendo qualcosa del genere:

 // Pseudocode

 // Just after fetching from api/pallets/list
 foreach pallet in clientApp.pallets {
     pallet.grower = clientApp.growers[pallet.growerId]
     pallet.species = clientApp.species[pallet.speciesId]
     pallet.caliber = clientApp.calibers[pallet.caliberId]
 }

 // growers is a dictionary with all the growers already downloaded from the server
 // species is a dictionary with all the species already downloaded from the server
 // calibers idem

Voglio sapere se questa è una buona o una cattiva idea per migliorare le prestazioni. Esiste un nome per questa pratica?

Il codice sarebbe molto più pulito senza una modifica come questa ma questo 5000 pallets jarray è troppo pesante. Nell'esempio sto solo mettendo 3 campi (coltivatore, specie, calibro) ma in realtà ce ne sono tipo 10. Tutti hanno id + nome + altri sottocampi ...

api performance json

posta sports 14.05.2017 - 10:42

fonte

2 risposte

Leggi altre domande sui tag api performance json

Qual è più pitone: controllando l'esistenza e non essere None, o usando la verità e get () con dicts? Percorso della struttura corretto per le risorse API di resto

score 2 · Answer 1

I want to know if this is a good or bad idea for improving performance. Is there a name for this practice?

Dipende dai tuoi requisiti specifici o dal problema di prestazioni specifico che stai tentando di risolvere. Fatti la seguente domanda: Ho davvero un problema con la dimensione dei dati di risposta?

Il tuo approccio mi fa pensare in cache o modalità offline .

Se i dati cambiano, il client rimane ignaro delle modifiche. Quindi hai due opzioni qui: sincronizzazione o ricarica tutti i dati memorizzati localmente e itera su tutte le 5k righe per recuperare gli oggetti nidificati.

Se devi ricaricare tutti i dati, dove sono i risparmi qui?

A meno che non siate preoccupati dalla larghezza di banda o dai vincoli del piano dati, non mi interesserebbe prematuramente la dimensione della risposta. Mi interesserebbe la lunghezza dell'array.

Se ridurre la dimensione dei dati di risposta è una priorità, abbiamo alternative.

Impaginazione : filtrato e ordinato è un vantaggio.

/api/pallets/list?page=0&pageSize=500

Rappresentanti dinamici : REST ci consente di chiedere rappresentazioni diverse di una determinata risorsa. Ad esempio:

/api/pallets/list?fields=id;name;growers.name; species.name

Mescola

/api/pallets/list?fields=id;name;growers.name;species.name&page=0&pageSize=500

Possiamo migliorare la soluzione con ETag . ETag è indirizzato a risparmiare larghezza di banda per non ridurre le chiamate al server.

Tutti gli approcci di cui sopra migliorano le prestazioni sul lato client. Quindi cosa succede sul lato server? Il server subisce un aumento del carico. Tuttavia, è più semplice ed economico scalare / uscire dal server rispetto al client.

Se non puoi permettervi l'impaginazione della lista, le rappresentazioni dinamiche possono essere d'aiuto. ETag è un vantaggio in ogni scenario.

score 1 · Answer 2

Per essere onesti, sarei totalmente seccato con te come utente di quell'API.

Ogni singola richiesta a un'API può fallire. Se fallisce, devo fare qualcosa al riguardo. Con la richiesta originale, ci sono due possibili risultati: o ho tutti i dati che voglio, o non ho niente. È molto facile da gestire. Con il tuo secondo approccio, QUALSIASI sottoinsieme delle informazioni che voglio che manchi. Questo è un ordine di grandezza più difficile da gestire.

E la raccomandazione di Laiv di consentire all'utente di scegliere i campi che desidera è piuttosto utile.

Ciò che ho trovato assolutamente strano è stato questo:

 grower: {
     growerId: 35,
 },

che avrebbe dovuto essere

 growerId: 35,

e nient'altro.