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 (recuperando dieci diverse risorse per una nuova schermata).
Ora, è una buona idea unire questi servizi a uno che fornisce tutti i dati richiesti, ma non è così "puro" in termini di principi REST? Ci sono significativi guadagni in termini di prestazioni?
Uno dei vantaggi di REST è la possibilità di memorizzare le richieste tramite le tradizionali cache http (supponendo che si tratti di richieste memorizzabili nella cache).
Quando hai richieste singole, più grandi, meno frequentemente utilizzate e possibilmente diverse (ho intenzione di recuperare gli elementi a,b,c,d questa volta e gli elementi a,b,d,e la prossima volta) rendi più probabile che la richiesta sia un errore di cache e scadono da una cache che potrebbe trovarsi da qualche parte tra te e il sorgente.
Considerate le due serie di richieste menzionate sopra, la seconda richiesta potrebbe avere una frequenza hit del 75% e recuperare sostanzialmente solo e , anziché tutte e quattro le cose.
Si noti che questo potrebbe non essere immediatamente evidente per le persone che lo utilizzano poiché la persona che esegue la prima serie di richieste di miss cache avrà ancora la mancanza della cache.
Questo non vuol dire che sarebbe l'ideale su una connessione di rete mobile in cui uno ha meno probabilità di ottenere hit della cache non locale. Ma per hot spot o altre situazioni wifi, gli hit della cache potrebbero essere molto più utili.
Molto di questo, ancora, è soggetto a come funziona la tua applicazione. Sta chiedendo tutti questi dati all'avvio? o stiamo parlando di un carico di pagina in cui le aspettative del tempo di risposta sono diverse?
La cosa ideale da fare sarebbe testare questo per vedere come la tua applicazione si preforma in una varietà di situazioni. Valuta la possibilità di configurare una situazione in cui hai collegato il tuo dispositivo mobile a una rete Wi-Fi locale che puoi monitorare (che è solo il primo hit su google) e simulazione di una cattiva connessione internet per vedere come funzionano (o non) effettivamente le cose e quale ha le migliori prestazioni.
La tua intuizione è alquanto corretta, ma in genere è preferibile fare meno richieste; API grosse tendono ad essere migliori. Soprattutto con la connettività spotty in cui è possibile vedere alcuni lavori e alcuni non riescono a creare scenari fallback da incubo in quanto nulla può contare su nulla.
C'è un grosso avvertimento: puoi diventare troppo massiccio e le chiamate e le risposte diventano gonfie. Ad esempio, potrebbe essere sensato avere una grossa chiamata quando apri per la prima volta una pagina e poi fai in modo che gli aggiornamenti eseguano lo streaming in morsi più piccoli piuttosto che forzare l'aggiornamento di una pagina grande ogni volta che desideri i dati.
Oppure, vorrai farlo in entrambi i modi con ogni probabilità.
Dai un'occhiata a questo articolo sul blog di Dropbox Tech .
Loro descrivono in dettaglio il motivo e il modo in cui hanno implementato esattamente la soluzione che hai proposto per il recupero delle miniature per tutte le tue immagini. Va detto che misurano le prestazioni per vedere se ne vale la pena, e apparentemente lo è.
Breve riassunto:
Il sito Web Dropbox deve caricare centinaia di miniature. A causa delle limitazioni in alcuni browser, non tutte le anteprime vengono caricate in parallelo (le richieste vengono accodate). Volevano utilizzare SPDY , ma non erano in grado di farlo perché alcune parti del loro sistema non lo supportano ancora. Alla fine hanno usato le richieste batch su HTTP, che restituiscono più miniature 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 è alquanto corretto e potrebbe trarre vantaggio da un servizio wrapper.
Questo servizio combina le singole chiamate esistenti in un unico metodo di servizio. In questo modo combinando le chiamate dal lato client a quello di servizio e amp; utilizzando tutte le chiamate singole, atomiche e restful che probabilmente hai già installato.
Pertanto, continuerai ad avere benefici da REST come la possibilità di memorizzare le richieste in cache.
Tuttavia, al punto finale tutto si ridurrà alle prestazioni dell'infrastruttura servizio / server e all'ambiente client che dovrebbero consumarlo.