PROGETTAZIONE API WEB: le richieste GET frammentate per costruire il contenuto di una pagina sono un sintomo di una progettazione errata?

2

Se mi trovo a recuperare un pezzetto di dati, e poi a recuperare i suoi "dati correlati" in una richiesta separata, è questa cattiva progettazione dell'API considerando che potrei impacchettare tutti questi dati in un unico oggetto di risposta?

Per fornire un contesto:

Se visualizzo la pagina di un prodotto, mi ritrovo a recuperare i dati specifici del prodotto e poi a recuperare dati correlati come "un elenco di prodotti correlati" o "un elenco di articoli correlati", ecc.

Apprezzerei anche se qualcuno potesse darmi qualche informazione sulla terminologia di ciò di cui sto parlando. Mi preoccupo principalmente di come impacchetta i dati, di come costruisco l'API e di come faccio a farlo in modo efficiente.

    
posta connected_user 23.10.2017 - 16:45
fonte

3 risposte

3

Potrebbe non essere considerato un cattivo design se l'interfaccia utente non sta facendo più richieste per le stesse informazioni più e più volte. Ci sono molti aspetti negativi, ma sembra che tu possa beneficiare di un altro livello API per consolidare le cose.

Ho ereditato un'app con un numero di controlli associati al servizio Web che effettuava un'altra chiamata Web quando impostava il suo stato iniziale anche se tale stato veniva fornito quando veniva caricata una pagina. Questo sarebbe un esempio di cattiva progettazione.

Ho anche lavorato su un'app con micro servizi e l'interfaccia utente doveva raccogliere informazioni da ciascun micro-servizio. Ogni chiamata è stata effettuata una sola volta e le chiamate Web sono state effettuate solo quando ne esisteva una ragione giustificabile (cioè cambiando effettivamente i dati).

Detto questo, framework come GraphQL e Falcor esistono a causa del livello di micro-servizi. Entrambi questi prodotti forniscono una API grafico per popolare e modificare i dati. Entrambi i prodotti gestiscono la memorizzazione nella cache lato client e lato server.

Pro e contro delle API Graph:

  • Consolida facilmente la chiamata per tutte le informazioni su una pagina in una
  • Gestisce le comunicazioni client / server per tuo conto (comprese le invalidazioni della cache)
  • La curva di apprendimento è molto ripida
  • I grafici non si associano sempre facilmente ai tuoi micro servizi

È davvero bello poter chiedere all'API del grafico, Falcor nel mio caso, di ottenere un elenco di elementi con le colonne specifiche che si desidera. Abbinare quello con un'interfaccia utente React era anche abbastanza facile da fare.

La sfida a cui mi sono imbattuto è che ora si ha un endpoint del server che a sua volta si integra con gli altri servizi Web per rispondere alle query del grafico. La creazione di percorsi e la risposta ad essi richiede un po 'di tempo per abituarsi, in particolare quando si modifica un campo su un dato necessario per aggiornare l'intero documento.

    
risposta data 23.10.2017 - 18:55
fonte
3

Tutto nel software è un compromesso correlato all'efficienza degli sviluppatori e alle prestazioni delle applicazioni. Stai riscontrando un carico eccessivo sul server a causa della richiesta extra? Qual è il motivo per cui non è possibile raggruppare le informazioni aggiuntive nella richiesta principale? Ci sono tonnellate di altre app che utilizzano la richiesta principale senza la necessità di ulteriori informazioni? Queste sono tutte domande che devi porsi, prima di decidere se o come modificare il codice. Se il software è logicamente meglio separato avendo il modo in cui è ora, e non si sta verificando alcun onere attuale sul server, lo lascerei così com'è, con forse solo un piano per il futuro se l'onere diventa evidente.

Di regola, non cerco di risolvere problemi che non ho! (Solitamente applicato a problemi di prestazioni del software rispetto alla manutenibilità)

    
risposta data 23.10.2017 - 17:07
fonte
-1

Sì.

È bello offrire / creare una API flessibile per cominciare. Ma alla fine della giornata si desidera ottimizzare in modo da poter server le pagine il più rapidamente ed economicamente (in termini di costi del server) possibile.

Non perderei completamente le API esistenti, ma aggiungerei una chiamata combinata che ti consente di salvare il round trip per il caso d'uso che hai.

Punta a caricare tutte le pagine dalla cache o dal CDN.

    
risposta data 23.10.2017 - 17:49
fonte

Leggi altre domande sui tag