È una buona idea unire più richieste HTTP per risparmiare larghezza di banda?

Sto preparando un'applicazione a pagina singola che a volte verrebbe utilizzata su una connessione mobile lenta. Alcune delle sue parti sono piuttosto pesanti in termini di richieste API (recupero di dieci risorse diverse per una nuova visualizzazione dello schermo).

Ora, è una buona idea unire questi servizi con uno che fornisce tutti i dati richiesti, ma non è "puro" in termini di principi REST? Ci sono significativi miglioramenti delle prestazioni previsti?

Uno dei vantaggi di REST è la possibilità di memorizzare nella cache le richieste tramite cache http tradizionali (supponendo che si tratti di richieste memorizzabili nella cache).

Quando hai richieste singole, più grandi, utilizzate meno frequentemente e forse diverse (ho intenzione di recuperare gli elementi a,b,c,dquesta volta e gli elementi la a,b,d,eprossima volta) rendi più probabile che la richiesta sia un errore nella cache e scada da una cache che potrebbe essere seduto da qualche parte tra te e la fonte.

Dati i due insiemi di richieste di cui sopra, la seconda richiesta può avere una percentuale di hit della cache del 75% ed essere sostanzialmente più veloce a recuperare e, piuttosto che tutte e quattro le cose.

Si noti che ciò potrebbe non essere immediatamente evidente alle persone che lo utilizzano, in quanto la persona che esegue la prima serie di richieste di mancata memorizzazione nella cache continuerà ad avere le mancanze della cache.

Questo non vuol dire che sarebbe l'ideale su una connessione di rete mobile in cui è meno probabile ottenere hit di cache non locali. Ma per gli hot spot o altre situazioni wifi, gli hit della cache potrebbero essere molto più utili.

Gran parte di questo, ancora una volta, è soggetto al funzionamento dell'applicazione. Chiede tutti questi dati all'avvio? o stiamo parlando di un caricamento della pagina in cui le aspettative sui tempi di risposta sono diverse?

La cosa ideale da fare sarebbe testare questo per vedere come l'applicazione si preforma in una varietà di situazioni. Prendi in considerazione la possibilità di impostare una situazione in cui hai associato il tuo dispositivo mobile a una rete Wi- Fi locale che puoi monitorare (che è solo il primo successo su Google) e simulare una cattiva connessione Internet per vedere come funzionano effettivamente le cose (o non farlo) e quale ha le migliori prestazioni.

La tua intuizione è in qualche modo corretta - nel complesso è sicuramente preferibile fare meno richieste; le API pesanti tendono ad essere migliori. Soprattutto con la connettività spotty dove puoi vedere un po 'di lavoro e alcuni non riescono a creare scenari di fallback da incubo poiché nulla può contare su nulla.

C'è un grande avvertimento: puoi diventare troppo grosso e le tue chiamate e le tue risposte diventano gonfie. Ad esempio, potrebbe avere senso effettuare una grande chiamata quando si accede per la prima volta a una pagina e quindi si esegue lo streaming degli aggiornamenti in morsi più piccoli invece di forzare un aggiornamento di una grande pagina ogni volta che si desiderano dati.

Oppure, vorrai farlo in entrambi i modi con ogni probabilità.

Dai un'occhiata a questo articolo di Dropbox Tech Blog .

Lì descrivono in dettaglio il perché e il modo in cui hanno implementato esattamente la soluzione che hai proposto per recuperare le miniature per tutte le tue foto. Va detto che misurano le prestazioni per vedere se vale la pena, e apparentemente lo è.

Breve riassunto:

Il sito web di Dropbox deve caricare centinaia di anteprime. A causa delle limitazioni in alcuni browser, non tutte le anteprime vengono caricate in parallelo (le richieste vengono messe in coda). Volevano usare SPDY , ma non erano in grado di farlo perché parti del loro sistema non lo supportano ancora. Alla fine hanno utilizzato richieste batch su HTTP, che restituiscono più anteprime per risposta in una forma compressa. Il miglioramento complessivo del tempo di caricamento della pagina è stato del 40% in base ai risultati.

In breve: il tuo approccio è in qualche modo corretto e potrebbe beneficiare di un servizio wrapper.

Questo servizio combinerà le singole chiamate esistenti in un unico metodo lato servizio. Farlo combinando le chiamate dal lato client al lato servizio e utilizzando tutte le chiamate singole, atomiche e riposanti che probabilmente sono già in atto.

Pertanto, si continuerebbe a beneficiare di REST come la possibilità di memorizzare nella cache le richieste.

Tuttavia, alla fine si ridurrà tutto alle prestazioni dell'infrastruttura del servizio / server e all'ambiente client che dovrebbe consumarlo.