API Class con richieste di rete intensive

È più conveniente per te se raccogli tutti i dati rilevanti (sull'utente, i follower, ecc.) in una sola routine. Non devi preoccuparti del partizionamento dell'accesso tra più chiamate o di avere alcune informazioni disponibili e altre no, ecc.

Ma avere una chiamata grande e clamorosa che richiede un (possibilmente) lungo tempo per essere eseguita, e consuma molte risorse del server sia locale che remoto per l'avvio - questa è una bassa scalabilità, design anti-sociale. Non sto dicendo mai, mai, ma è molto più appropriato nei prototipi esplorativi che nel codice di produzione.

Se desideri che il tuo oggetto User copra le interazioni con l'API REST, il tuo metodo getFollowers dovrebbe richiamare il shuffle dietro le quinte richiesto per catturare le informazioni dei follower, quindi salvarlo in locale. Questo è del tutto appropriato e tipico. Mentre la prima richiesta richiederà molto più tempo rispetto alle richieste successive, c'est la vie.

A meno che non ci si trovi in una situazione di alta limitazione delle prestazioni o di latenza, è improbabile che si desideri coinvolgere meccanismi di richiesta / restituzione asincroni. Sono complicati per avere ragione, e in particolare complicano sia la tua logica sia quella di User di consumatori.

Vedete chiamate asincrone spesso in JavaScript - insieme a un esercito di gestori di callback, gestori di eventi registrati, promesse, futures e altre tecniche di rendez-vous. Questo perché JS non ha altri buoni meccanismi per gestire il threading / la concorrenza e async è diventato l'idioma del linguaggio. È possibile effettuare chiamate asincrone in Java, ad esempio con Futures . In generale, i programmi Java tendono a privilegiare i thread rispetto alle chiamate asincrone e i consumatori di API Java si aspettano prevalentemente metodi sincroni. A meno che tu non abbia un requisito specifico per fare le cose asincrone, o se credi di farlo, otterrai una sostanziale vittoria prestazioni / latenza, non farlo. Non fare cose che richiedono ai tuoi consumatori di adottare un modello inatteso di concorrenza.

Nota anche che molte API REST sono paginate . Richieste come "get followers" o "get posts" restituiscono il primo 20, 50 o qualsiasi altra cosa. Ottenere i prossimi oggetti N richiede una chiamata successiva. In questi casi, effettuare chiamate API di rete / REST è qualcosa che i tuoi metodi getter potrebbero dover fare per tutta la vita degli oggetti User , non solo una o due volte "in primo piano".

Per me la soluzione migliore sembra essere un metodo che accetta un parametro facoltativo che consente al chiamante di determinare se includere o meno i dati follower. In questo modo il chiamante può determinare se è appropriato includere i dati del follower nella chiamata.

Nel peggiore dei casi si hanno alcune righe aggiuntive di codice che non hanno mai importanza perché la chiamata vuole sempre tutti i dati. Tuttavia, se il chiamante non ha bisogno di tutti questi dati e l'applicazione rileva alcuni risultati di prestazioni dalla raccolta dei dati aggiuntivi, è possibile eseguire alcune regolazioni fini per consentire il caricamento condizionale dei dati follower.

D'altro canto, se lo si codifica in modo fisso per ottenere sempre i dati follower, se diventa un problema di prestazioni, la modifica sarà più efficace se si deve apportare la modifica per consentirne la chiamata o per effettuare una chiamata separata che ottiene solo le informazioni dell'utente. L'implementazione del parametro opzionale ora dovrebbe essere un'attività banale e consentire la migliore messa a punto dell'applicazione senza dover modificare l'API.