Qual è la dimensione di risposta ideale da considerare quando si progettano oggetti API e oggetti secondari

Penso che sia importante distinguere tra medio tempo di risposta e assoluto tempo di risposta. Secondo la pagina delle metriche a cui sei collegato, questo è esattamente ciò che fa GitHub. Tracciano 2 parametri relativi ai tempi di risposta:

• media (media)
• 98 ° percentile

Questo fornisce 2 immagini: il tempo di risposta che la maggior parte delle persone affronta e i peggiori tempi di risposta delle persone.

La prossima domanda è dove si misura il tempo di risposta. Se si misura il tempo di risposta dai registri di accesso del server Web (come fa la maggior parte delle persone), si misura il delta da quando la richiesta viene ricevuta all'ora in cui il server invia la risposta, escluso il tempo di trasferimento. Se si misura il tempo di risposta dall'interno della scheda dello sviluppatore di un browser, si sta misurando il tempo dal momento in cui è stata inviata la richiesta al momento in cui la risposta è stata completamente ricevuta, che include 2 viaggi di rete nei tempi.

Riduzione al minimo del tempo di rete

C'è molto poco che puoi fare per migliorare i tempi di trasferimento dei dati. Le velocità di rete sono in genere limitate in luoghi in cui non si ha il controllo. Tuttavia, puoi eseguire le seguenti operazioni:

• Abilita la compressione HTTP . JSon e XML sono altamente comprimibili, quindi potresti risparmiare anche un po 'di soldi.

Metriche coerenti

Assicurati di sapere cosa stai misurando e perché esistono questi parametri. Tieni presente che noi umani abbiamo difficoltà a percepire differenze temporali inferiori a 100ms (1/10 di secondo).

Progettazione in base alle tue esigenze

Progetta le tue API in base alle tue esigenze. Se qualcosa diventa un vero e proprio collo di bottiglia, puoi vedere come puoi migliorare o ottimizzare in quel momento.

• Se si dispone di client che richiedono il payload completo, disporre di un endpoint API per il carico utile completo
• Se disponi di client che necessitano di un payload abbreviato, disponi di un endpoint API per tale payload abbreviato
• Non pensare alle dimensioni dei dati assoluti. Pensa al bisogno reale. Il ripristino di set di dati appropriati riduce al minimo le chiamate API.

È normale che sia necessario un elenco di dati di riepilogo e quindi richiedere un carico utile completo quando l'utente è pronto a eseguire il drill nelle informazioni.

La dimensione di risposta ideale per ogni richiesta è la dimensione più piccola possibile che contiene tutte le informazioni necessarie al cliente. Avere clienti che fanno richieste multiple è inefficiente e dovrebbe essere evitato.

Sembra che tu abbia più client che hanno bisogno di diversi sottoinsiemi di informazioni, che inviano come se mettessero quei due requisiti in disaccordo. Per evitare che il client A faccia richieste multiple, sembra che potrebbe essere necessario inviare alcuni dati di cui il cliente B non ha bisogno. Ma ciò che puoi fare è includere un'opzione nella richiesta che specifica quale sottoinsieme di informazioni è necessario . Quindi, quando il cliente A si connette può chiedere è foos con barre incluse, mentre il client B può averne senza.

Dai un'occhiata ad alcune API di Google per gli esempi: lo fanno molto.