Progettazione API REST: chiamate multiple vs. chiamata singola all'API

Stiamo sviluppando un'API Rest per il sito Web di eCommerce che verrà utilizzata dalle app mobili.

Nella home page di un'app dobbiamo chiamare più risorse come dispositivi di scorrimento, marchi migliori, prodotti più venduti, prodotti di tendenza, ecc.

Due opzioni per effettuare chiamate API:

Chiamata singola:

www.example.com/api/GetAllInHome

Chiamate multiple:

www.example.com/api/GetSliders

www.example.com/api/GetTopBrands

www.example.com/api/GetBestSellingProducts

www.example.com/api/GetTrendingProducts

Qual è l'approccio migliore per la progettazione di API a riposo - chiamata singola o multipla, spiegare i pro ei contro?

Che ci vorrà più tempo per rispondere alla richiesta?

— shaijut
fonte

Risposte:

In Teoria le chiamate simultanee multiple sono più flessibili e altrettanto veloci.

Tuttavia, in pratica se si carica una pagina e quindi si carica ciascuna parte di quella pagina, visualizzando il caricamento di filatori su di essa fino a quando non si ottengono i risultati, il risultato è lento e disgiunto.

Per questo motivo le richieste di dati AJAX devono essere utilizzate con parsimonia e solo quando si dispone di una sezione della pagina che è lenta da caricare o deve essere aggiornata in un ciclo diverso rispetto al resto della pagina. Pronuncia un display principale / dettaglio, in cui desideri selezionare un'opzione dal master e visualizzare i dettagli corrispondenti senza ricaricare il master.

Un progetto comune consiste nel mantenere le API separate per la flessibilità di codifica e le preoccupazioni relative ai micro-servizi, ma combinare il lato server di dati nel sito Web. pertanto il cliente deve effettuare una sola chiamata al proprio sito Web. Le chiamate API con la memorizzazione nella cache appropriata dovrebbero essere veloci all'interno del data center.

Inoltre, considera di NON avere affatto chiamate API client. semplicemente generare il lato server HTML. Sebbene i framework di app a pagina singola javascript ti spingano verso il basso sulla rotta API. Di solito non è l'approccio ottimale per i siti di e-commerce ad alto volume.

— Ewan
fonte

Grazie, in realtà questo api viene consumato nelle app per Android e per telefono, voglio sapere quando viene caricata la home page dell'app se dovessi ottenere tutte le risorse come: cursori, marchi, prodotti in una singola chiamata api o effettuare una chiamata individuale a api per singola risorsa quando gli utenti scorre verso il basso?

— Shaijut

Si applica la stessa logica, minimizzare le chiamate simultanee dove non richiesto. Un'app ti offre un po 'più di flessibilità per scaricare informazioni in background. Potresti voler passare a un approccio GetChangesSInce (data)

— Ewan

Quindi concludi, è meglio avere un'unica API per chiamare tutte le risposte delle risorse della home page contemporaneamente quando la home page dell'app viene caricata e avere diverse API per slider, marchi ecc. Separatamente per il micro-servizio quando hai una sezione della pagina da aggiornare ?

— shaijut

a meno che tu non abbia una buona ragione per cui quelle sezioni non sono solo caricate con la pagina / i dati principali

— Ewan

Ho l'ultima domanda su come funzionerebbero app come Amazon, flipkart? Non caricano tutte le risorse della home page in una sola chiamata quando l'utente apre l'app? Voglio sapere quale sarebbe il miglior approccio al riguardo.

— Shaijut

TL; DR: a parte tutte le altre considerazioni sull'applicazione, l'esecuzione di una singola chiamata sarebbe più rapida rispetto all'esecuzione di più chiamate. L'esecuzione delle chiamate in modo asincrono può ridurre il tempo complessivo necessario per completare una determinata operazione dal punto di vista dell'utente (che potrebbe essere tutto ciò di cui hai bisogno), ma nel complesso, il tempo impiegato sarebbe ancora più lungo per più chiamate.

Nel tuo caso, tuttavia, non sono sicuro che sia la storia completa.

Le API REST sono un termine leggermente ambiguo, a causa di varie interpretazioni del documento che ha reso l'idea popolare. Tuttavia, anche con l'interpretazione più liberale di ciò che costituisce un'API REST, ciò che hai non si adatta davvero.

Il principio fondamentale è che hai una risorsa su cui vuoi eseguire un'azione. L'URI identifica la risorsa che ti interessa e normalmente useresti i verbi HTTP per indicare cosa vuoi fare a quella risorsa.

Nel tuo caso specifico, tutti i tuoi metodi hanno la parola "get" nel loro nome. Dovresti cambiare il verbo usato nella richiesta HTTP per indicare che vuoi "ottenere" la risorsa disponibile in quella posizione.

Il tuo schema URI dovrebbe rappresentare la gerarchia logica delle risorse che vuoi rendere disponibili agli utenti della tua API, quindi nel tuo caso prenderei in considerazione l'uso di qualcosa come /api/products?category=slidersfiltrare la tua raccolta di prodotti. Ciò significa che quando i clienti desiderano ottenere tutti i tuoi prodotti, possono semplicemente omettere la stringa di query.

— richzilla
fonte

Grazie, quindi intendi single urlper API ma la richiesta dovrebbe essere fatta a risorse diverse usando Query String? , controlla anche questo .

— shaijut

Sì, l'esecuzione delle chiamate in modo asincrono ridurrebbe il tempo assoluto necessario per recuperare i dati, ma nel complesso il tempo impiegato sarà ancora maggiore; Altre chiamate devono ripetere l'overhead di una connessione TCP e un round trip di comunicazione. Anche usando funzioni come keep-alivearent lo rimuoverà del tutto.

— Richzilla,

La categoria sarebbe una proprietà di una singola risorsa di prodotto. Logicamente dovresti recuperare una raccolta di prodotti e filtrare tutti quelli con la categoria specificata

— richzilla

quindi vuoi dire, quando l'utente apre la home page dell'app, una chiamata dovrebbe andare all'API che restituisce tutte le risorse di cui sopra? o quando scorre le chiamate individuali dovrebbero essere fatte per risorse specifiche che è la migliore pratica?

— shaijut

Dipende da ciò che l'utente si aspetta di vedere in ogni punto dell'applicazione. Prendi questo sito Web ad esempio, quando fai clic su questionsvedi che l'URI è /questions, quando fai clic su uno dei tuoi tag preferiti, l'URI è/questions/tagged/<tagname>

— richzilla