Invio di una raccolta di dati a un'API. Chiamate multiple multiple rispetto a una chiamata grande

7

Attualmente sto creando un'API e implementato alcune azioni di base REST come ottenere, aggiornare, cercare, ecc. Un altro programma che raccoglie i dati deve sincronizzarli con questa API. Il mio attuale pensiero è: quale sarebbe una buona pratica per sincronizzare questi dati?

Alcune informazioni: La quantità di dati che deve essere sincronizzata è diversa tra le applicazioni. Alcuni possono trasferire 100 record al minuto, altri 10k record al minuto. Ci sarà un limite di trasferimento all'ora per mantenere il carico del server bilanciato. Inoltre, le richieste sono firmate con un token per verificare l'autenticità.

Ecco un piccolo elenco di pro / contro che ho creato proprio ora. Non sono sicuro se questi sono veri pro / contro, né sono sicuro che dovrei pesarne alcuni.

Opzione 1 Passa in rassegna questi dati e crea una chiamata API per ogni record.

Pro:

  • si integra meglio con l'attuale API REST
  • le voci di sincronizzazione non riuscite possono essere messe in coda per un nuovo invio

Contro:

  • un sovraccarico maggiore a causa di più chiamate

Opzione due
Crea un pacchetto di tutti quei dati e invia su quel pacchetto in una sola chiamata.

Pro:

  • meno spese generali
  • una sola query

Contro:

  • l'errore di trasferimento può far cadere tutti i dati
  • implementazione separata per consentire
posta pduersteler 09.02.2012 - 17:07
fonte

1 risposta

6

Generalmente, il sovraccarico di avviare e terminare la richiesta remota è abbastanza alto da consentire il batch delle chiamate. Esattamente dove questa linea è realmente dipende da quanti dati sono coinvolti qui per dire dove dovrebbero essere le linee di batching. In realtà non dovrebbe essere un sovraccarico per far sì che il sistema di ricezione gestisca i lotti - i computer sono davvero bravi a "eseguire nuovamente questa funzione con nuovi parametri" l'ultima volta che ho controllato.

Da una prospettiva logica, un batch sarebbe considerato una transazione nel tipico senso del database? Se è così, ha anche un sacco di senso lasciarlo viaggiare e avere successo (o fallire) insieme piuttosto che cercare di capire come diffondere una singola transazione logica su transazioni fisiche separate.

Ciò che mi spingerebbe a fare singole chiamate è se ogni richiesta avesse un sacco di dati coinvolti - almeno centinaia di KB - o se le cose dovessero essere un po 'più in tempo reale e non si poteva aspettare di costruire lotti .

    
risposta data 09.02.2012 - 17:31
fonte

Leggi altre domande sui tag