È utile per le operazioni di lettura / scrittura che coinvolgono più di 100 Gig

The answer discusses in general the aspect of sending large data over HTTP using REST. Make sure you also read the answer by Robert Jack Will which is more specific and suggests a way which makes it possible to avoid sending large data in the first place.

REST non ha nulla a che fare con XML: il formato dei dati, sarebbe JSON, XML, testo normale o flusso binario, è irrilevante. Ad esempio, puoi pubblicare immagini (JPEG, PNG ...) tramite REST, il che non significa che devi includerle in XML.

D'altra parte, REST è basato su HTTP e HTTP è adatto per grandi trasferimenti di dati. Certo, devi stare attento quando configura sia il tuo servizio che il tuo client per utilizzare i flussi quando scarichi dati così grandi, invece di caricarli in memoria.

Per quanto riguarda il formato effettivo dei dati:

• Se è imperativo mantenere una struttura di auto-documentazione, usa JSON, XML o testo semplice , ma assicurati di comprimere il contenuto sul server prima di inviarlo. La scelta dell'algoritmo di compressione dipenderà dalla tua piattaforma e dai requisiti di interoperabilità, dato che formati proprietari come RAR possono spesso ottenere un migliore rapporto di compressione (ancora, fai il test con i tuoi dati per vedere quanto bene gli algoritmi eseguono).

  Si noti che potrebbe non essere così facile trovare un serializzatore / deserializzatore per XML o JSON che produrrà / accetterà un flusso invece di una stringa. In questo caso, il testo normale potrebbe essere la scelta migliore.

• Se la struttura di autocodifica non è richiesta, il formato binario potrebbe essere un'alternativa migliore in termini di dimensioni. Ancora, effettua un confronto effettivo tra dati compressi in testo normale e dati binari per vedere quale produce risultati più piccoli; potresti essere sorpreso.

Per quanto riguarda se e come utilizzare HTTP per il trasferimento dei dati, sono completamente d'accordo con la risposta di MainMa.

Tuttavia, indipendentemente dalla dimensione dei dati, il processo che descrivi non sembra una tipica applicazione per Rest. Una delle idee principali di Rest è quella di aver chiamato risorse come mycompany.com/claims/customer/{number}/claim/{number} che possono essere interrogate e aggiornate individualmente.

Il tuo problema, d'altra parte, somiglia più all'elaborazione in batch: hai una grande quantità di dati, inclusi anche gli indici, e dal momento che vuoi eseguire i rapporti su di essi in seguito, perché non li memorizzi in un database o motore di analisi come Elastic Search? A questo punto, la logica di reporting può interrogare in modo efficiente il database / motore di ricerca e fornire il rapporto risultati tramite Rest: mycompany.com/healthreport/{year}/{month}/claimsdata/{region} o somesuch.

A seconda di quante entità e relazioni hai, il marshalling di tutti questi dati nel suo percorso dal motore ET al generatore di report può essere molto impegnativo e vale la pena se devi separare questi due stadi da un grande estendere. (Ad esempio, quando operano in organizzazioni / società IT indipendenti). L'uso di basi di dati separate può già fornire una certa quantità di disaccoppiamento con uno sforzo minore.