Devo analizzare XML sul server o fornire un proxy e lasciare che il browser lo analizzi?

Devo interfacciarmi con un'API di terze parti. Con questa API faccio una richiesta GET dal browser dell'utente finale e ricevo una risposta XML. Questi dati devono essere utilizzati in un'applicazione basata su browser in cui l'utente può cercarli, usarli per prendere decisioni, ecc. Il problema principale è che la maggior parte dei browser ha bloccato l'uso di XML tra domini, quindi non riesco semplicemente a ottenere l'XML dall'API.

I dati complessivi, tuttavia, sono sostanzialmente suddivisi in due set.

1. Il primo set di dati è pubblico e deve essere aggiornato solo ogni tanto, quindi può essere memorizzato nella cache per tutti gli utenti sul lato server, alleggerendo notevolmente il traffico.
2. Il secondo set di dati è privato e individuale per ciascun utente. Questi dati vengono inoltre aggiornati più frequentemente nell'API. Ciò porta la memorizzazione nella cache ad essere molto meno efficace.

Per motivi di scalabilità, vorrei mantenere il carico del server il più piccolo possibile.

Vedo due opzioni prima di me:

1. Fornire un proxy che può essere utilizzato per instradare le richieste XML al server di terze parti e direttamente avanti e indietro tra client e API di terze parti.
2. Chiedi al server di eseguire la conversione da XML a JSON e di eliminare le informazioni non necessarie. Ciò significa essenzialmente creare una nuova API per il nostro server, che si traduce in richieste dall'API di terze parti

Quale sarebbe il modo migliore per fornire i dati all'utente? (Non deve essere una delle due opzioni)

L'opzione proxy è la più semplice da implementare. Non hai alcuno sviluppo personalizzato da fare, l'unica cosa da fare è impostare un proxy. È anche semplice: non esiste un codice aggiuntivo da mantenere e, se l'API cambia, non è necessario apportare modifiche dalla propria parte.

Un proxy sarebbe una scelta preferita:

• Se è necessario spedire velocemente il software di lavoro. Questo lo rende una buona scelta, ad esempio, se stavi per spedire una funzione, ma durante la fase di implementazione del progetto hai scoperto che non puoi semplicemente fare richieste AJAX tra domini.

• O se l'API corrente è ben progettata : l'architettura è buona, le chiamate sono molto chiare, la documentazione è completa e di facile comprensione.

• O se l'API corrente è soggetta a modifiche. Se cambia, devi solo cambiare l'implementazione JavaScript. Se invece di un proxy, stai analizzando i risultati e generando il tuo JSON, c'è il rischio che le modifiche all'API richiedano le modifiche nel tuo codice lato server.

D'altro canto, l'analisi del risultato ha un vantaggio per consentire di estrarre completamente l'API dal lato client. Questa è un'alternativa più lenta, poiché richiede di progettare la nuova interfaccia (se l'API originale non è ben progettata) e di implementare le funzioni di estrazione, trasformazione e caricamento, ma può essere una buona scelta a lungo termine per un grande progetto. Questa è una scelta preferita:

• Se hai bisogno di funzionalità aggiuntive. È possibile sfruttare le diverse funzionalità che non erano disponibili nell'API originale, come la memorizzazione nella cache a un livello non supportato da un normale server proxy, la crittografia o un diverso modello di autenticazione .

  Ad esempio, se il numero di richieste AJAX diventa un problema o se il modello di comunicazione bidirezionale ha senso, è possibile implementare Web Socket.

• O se l'API corrente non è ben progettata. Come un modello di facciata, questo approccio consente di riprogettare l'API. Se l'originale è scadente, avere una facciata consente di risolvere le cattive scelte progettuali fatte dagli autori originali di un'API legacy. Puoi agire anche su parti di grandi dimensioni, come l'architettura generale dell'API, ma anche sui dettagli, come i nomi degli argomenti o i messaggi di errore.

  Mentre la modifica di un'API esistente è talvolta impossibile, avere una facciata può consentire di lavorare con un codice pulito che elimina gli svantaggi e gli errori nel progetto originale.

• O se l'API corrente è soggetta a modifiche. In effetti, potresti preferire cambiare il codice lato server anziché JavaScript se l'API cambia nel tempo, mantenendo inalterata l'interfaccia pubblica della tua facciata. Potrebbe essere più semplice perché hai più esperienza con la programmazione lato server o perché conosci più strumenti per il refactoring lato server o perché nel tuo progetto è più semplice gestire il controllo delle versioni del codice lato server.

Potresti notare che ho omesso di parlare di JSON, prestazioni, cache, ecc. C'è una ragione per questo:

• JSON vs. XML: sta a te scegliere la tecnologia giusta . Lo fai misurando obiettivamente il surriscaldamento di XML su JSON, il tempo necessario per serializzare i dati e la facilità di analisi.

• Prestazioni: confronta diverse implementazioni, scegli la più veloce, quindi profilala e ottimizzala in base ai risultati del profiler. Interrompere quando si ottengono le prestazioni specificate nei requisiti non funzionali.

  Inoltre, capisci cosa stai cercando di ottenere. Esistono diverse parti che interagiscono tra loro: l'API originale, la larghezza di banda tra il tuo server e quella dell'API, le prestazioni del tuo server, la larghezza di banda tra il tuo server e gli utenti finali e le prestazioni delle loro macchine. Se ti viene chiesto di ottenere una risposta a una richiesta entro 30 ms., Ma l'API originale impiega 40 ms. elaborando la richiesta, qualunque cosa tu faccia, non sarai in grado di ottenere le prestazioni richieste.

• Memorizzazione nella cache : la memorizzazione nella cache è una delle tecniche per rendere più veloce la tua applicazione web, riducendo la larghezza di banda, ecc.

  1. Assicurati di utilizzare anche la memorizzazione nella cache del client (la memorizzazione nella cache sul lato server non ridurrà l'utilizzo della larghezza di banda tra te e i clienti), dato che l'impostazione delle intestazioni HTTP correttamente è spesso complicata.

  2. Assicurati di determinare correttamente cosa memorizzare nella cache, per quanto tempo e quando invalidarlo: se la descrizione del prodotto è cambiata 10 secondi fa, ma i clienti di un sito di e-commerce vedono ancora la vecchia versione, va bene. Se il proprietario ha modificato la descrizione, l'ha inviata e vede ancora la variante precedente a causa della memorizzazione nella cache, questo è problematico.

  3. Non concentrarti solo sulla memorizzazione nella cache. Anche la minimizzazione è importante. Ridurre il numero di richieste può anche essere utile.

C'è una terza opzione che potresti non aver visto: Condivisione delle risorse incrociate (CORS) .

Lo standard CORS funziona aggiungendo nuove intestazioni HTTP che consentono ai server di fornire risorse ai domini di origine consentiti. I browser supportano queste intestazioni e rispettano le restrizioni stabilite.

Esempio : supponi che il tuo sito sia http://my-cool-site.com e che tu abbia un'API di terze parti sul dominio http://third-party-site.com , a cui puoi accedere tramite AJAX.

E supponiamo che una pagina che tu server da my-cool-site.com abbia fatto una richiesta a third-party-site.com. Normalmente, il browser degli utenti rifiuta le chiamate AJAX verso qualsiasi altro sito diverso dal proprio dominio / sottodominio secondo la Politica di sicurezza della stessa origine . Ma se il browser e il server di terze parti supportano CORS, si verificano le seguenti cose:

• Il browser invierà la seguente intestazione HTTP a third-party-site.com

  Origin: http://my-cool-site.com

• Se il server di terze parti accetta richieste dal tuo dominio, risponderà con la seguente intestazione HTTP:

  Access-Control-Allow-Origin: http://my-cool-site.com

• Per consentire tutti i domini, un server di terze parti può inviare questa intestazione:

  Access-Control-Allow-Origin: *

• Se il tuo sito non è consentito, il browser genererà un errore.

Se i client hanno browser abbastanza moderni che supportano CORS e anche il tuo server di terze parti supporta CORS , puoi sicuramente provarlo con piccole modifiche al tuo codice.

Ho trovato una bella spiegazione su CORS , su cui troverai anche un altro modo per farlo: JSONP . Ma JSONP richiederebbe una discreta quantità di modifiche al tuo codice.

Per effettuare una richiesta CORS è sufficiente utilizzare XMLHttpRequestin Firefox 3.5+, Safari 4+ e Chrome e XDomainRequestoggetti in IE8 +. Quando si utilizza l' XMLHttpRequestoggetto, se il browser rileva che si sta tentando di effettuare una richiesta tra domini, attiverà senza problemi il comportamento CORS.

Ecco una funzione javascript che ti aiuta a creare un oggetto CORS tra browser.

function createCORSRequest(method, url){
    var xhr = new XMLHttpRequest();
    if ("withCredentials" in xhr){
        // XHR has 'withCredentials' property only if it supports CORS
        xhr.open(method, url, true);
    } else if (typeof XDomainRequest != "undefined"){ // if IE use XDR
        xhr = new XDomainRequest();
        xhr.open(method, url);
    } else {
        xhr = null;
    }
    return xhr;
}

Dato che dici che "la maggior parte dei browser ha bloccato l'uso di XML tra domini", immagino che il tuo server di terze parti potrebbe non supportare CORS. Quindi devi trovare approcci alternativi.

Per motivi di scalabilità, vorrei mantenere il carico del server il più piccolo possibile

Penso che questo indichi più o meno la risposta. La fornitura o meno di dati preelaborati al cliente dipende principalmente da:

1. la differenza rispetto al traffico
2. l'impatto delle prestazioni dell'elaborazione
3. l'impatto di un diverso formato di dati sul client

Se l'XML è relativamente piccolo o ci sono solo poche richieste, può avere senso inoltrarlo al client e dimenticarlo. Lo stesso vale quando i dati preelaborati sono ancora una grande parte dei dati originali o se il client non è in grado di trarre grandi vantaggi da un formato di dati diverso (ad esempio JSON).

Tuttavia, se il client ha difficoltà a elaborare un set di dati XML di grandi dimensioni o se il client necessita solo di una piccola parte dei dati XML originali, può avere senso eseguire una pre-elaborazione sul lato server.

Alla fine, è più facile ridimensionare un server, piuttosto che ridimensionare un client / browser o la larghezza di banda disponibile. Per dirla in una frase, dipende da dove si trova il collo di bottiglia nel sistema.

La mia scelta sarebbe quella di memorizzare nella cache e comprimere (gettare via le informazioni non necessarie) e gzip i risultati nel browser del client, l' opzione n . 2 . Poiché i browser non sono in genere CPU di fascia alta e le linee di rete dal server al browser hanno una capacità limitata. Sto parlando di client mobili . Se non prevedi di supportare i client mobili, scegli quello che è più semplice, ad esempio alcuniGoogle:CORS proxy