Dois-je analyser XML sur le serveur ou fournir un proxy et laisser le navigateur l'analyser?

Je dois m'interfacer avec une API tierce. Avec cette API, je fais une demande GET depuis le navigateur de l'utilisateur final et je reçois une réponse XML. Ces données doivent être utilisées dans une application basée sur un navigateur où l'utilisateur peut les parcourir, les utiliser pour prendre des décisions, etc. Le problème principal est que la plupart des navigateurs ont verrouillé l'utilisation XML entre domaines, donc je ne peux pas simplement le XML de l'API.

Cependant, les données globales sont fondamentalement divisées en deux ensembles.

1. Le premier ensemble de données est public et ne doit être mis à jour que de temps en temps, il peut donc être mis en cache pour tous les utilisateurs côté serveur, ce qui allège considérablement le trafic.
2. Le deuxième ensemble de données est privé et individuel pour chaque utilisateur. Ces données sont également mises à jour plus fréquemment dans l'API. Cela rend la mise en cache beaucoup moins efficace.

Pour des raisons d'évolutivité, je voudrais garder la charge du serveur aussi petite que possible.

Je vois deux options devant moi:

1. Fournissez un proxy qui peut être utilisé pour acheminer les requêtes XML vers le serveur tiers et directement dans les deux sens entre le client et l'API tierce.
2. Demandez au serveur d'effectuer la conversion de XML en JSON et de supprimer les informations inutiles. Cela signifie essentiellement créer une nouvelle API pour notre serveur, ce qui se traduit par des demandes de l'API tierce

Quelle serait la meilleure façon de fournir les données à l'utilisateur? (Ne doit pas nécessairement être l'une des deux options)

L'option proxy est la plus simple à implémenter. Vous n'avez aucun développement personnalisé à faire, la seule chose à faire est de configurer un proxy. C'est aussi simple: il n'y a pas de code supplémentaire à maintenir, et si l'API change, vous n'avez aucune modification à apporter de votre côté.

Un proxy serait un choix préféré:

• Si vous devez expédier rapidement un logiciel fonctionnel. Cela en fait un bon choix, par exemple, si vous étiez sur le point d'expédier une fonctionnalité, mais que vous constatiez pendant la phase de mise en œuvre du projet que vous ne pouvez pas simplement faire des demandes AJAX interdomaines.

• Ou si l'API actuelle est bien conçue : l'architecture est bonne, les appels sont très clairs, la documentation est complète et facile à comprendre.

• Ou si l'API actuelle est susceptible de changer. S'il change, il vous suffit de changer l'implémentation JavaScript. Si au lieu d'un proxy, vous analysez les résultats et générez votre propre JSON, il y a un risque que les modifications de l'API nécessitent les modifications dans votre code côté serveur.

D'un autre côté, l'analyse du résultat présente l'avantage de permettre d'abstraire complètement l'API côté client. Il s'agit d'une alternative plus lente, car elle nécessite de concevoir la nouvelle interface (si l'API d'origine n'est pas bien conçue) et de mettre en œuvre les fonctionnalités d'extraction, de transformation et de chargement, mais cela peut être un bon choix à long terme pour un grand projet. Ceci est un choix préféré:

• Si vous avez besoin de fonctionnalités supplémentaires. Vous pouvez exploiter les différentes fonctionnalités qui n'étaient pas disponibles dans l'API d'origine, telles que la mise en cache à un niveau qui n'est pas pris en charge par un serveur proxy ordinaire, ou le cryptage , ou un modèle d' authentification différent .

  Par exemple, si le nombre de demandes AJAX devient un problème ou si le modèle de communication bidirectionnel est logique, vous pouvez implémenter des sockets Web.

• Ou si l'API actuelle n'est pas bien conçue. Comme un motif de façade, cette approche vous permet de repenser l'API. Si l'original est médiocre, avoir une façade permet de résoudre les mauvais choix de conception faits par les auteurs originaux d'une API héritée. Vous pouvez également agir sur de grandes parties, telles que l'architecture globale de l'API, mais également sur des détails, tels que les noms des arguments ou les messages d'erreur.

  Bien qu'il soit parfois impossible de modifier une API existante, avoir une façade peut permettre de travailler avec un morceau de code propre qui résume les inconvénients et les erreurs de la conception d'origine.

• Ou si l'API actuelle est susceptible de changer. En effet, vous préférerez peut-être changer le code côté serveur au lieu de JavaScript si l'API change au fil du temps, tout en gardant l'interface publique de votre façade inchangée. Cela peut être plus facile soit parce que vous êtes plus expérimenté avec la programmation côté serveur, soit parce que vous connaissez plus d'outils de refactorisation côté serveur, soit parce qu'il est plus facile dans votre projet de gérer le versioning de code côté serveur.

Vous remarquerez peut-être que j'ai omis de parler de JSON, des performances, de la mise en cache, etc. Il y a une raison à cela:

• JSON vs XML: à vous de choisir la bonne technologie. Pour ce faire, vous mesurez objectivement la surchauffe de XML sur JSON, le temps nécessaire pour sérialiser les données et la facilité d'analyse.

• Performances: comparer différentes implémentations, choisir la plus rapide, puis la profiler et l'optimiser en fonction des résultats du profileur. Arrêtez-vous lorsque vous atteignez les performances spécifiées dans les exigences non fonctionnelles.

  Comprenez également ce que vous essayez de réaliser. Plusieurs parties interagissent entre elles: l'API d'origine, la bande passante entre votre serveur et celle de l'API, les performances de votre serveur, la bande passante entre votre serveur et les utilisateurs finaux et les performances de leurs machines. Si vous êtes invité à obtenir une réponse à une demande dans les 30 ms., Mais l'API d'origine passe 40 ms. En traitant la demande, quoi que vous fassiez, vous ne pourrez pas obtenir les performances requises.

• Mise en cache: la mise en cache est l'une des techniques pour rendre votre application Web plus rapide, réduire la bande passante, etc.

  1. Assurez-vous également d'utiliser la mise en cache client (la mise en cache côté serveur ne réduira pas l'utilisation de la bande passante entre vous et les clients), car la configuration correcte des en-têtes HTTP est souvent délicate.

  2. Assurez-vous de déterminer correctement ce qui doit être mis en cache, pour combien de temps et quand l'invalider: si la description du produit a changé il y a 10 secondes, mais que les clients d'un site de commerce électronique voient toujours l'ancienne version, c'est OK. Si le propriétaire a modifié la description, l'a soumise et voit toujours la variante précédente en raison de la mise en cache, cela pose problème.

  3. Ne vous concentrez pas uniquement sur la mise en cache. La minification, par exemple, est également importante. La réduction du nombre de demandes peut également être bénéfique.

Il existe une troisième option que vous n'avez peut-être pas vue: le partage des ressources d'origine croisée (CORS) .

La norme CORS fonctionne en ajoutant de nouveaux en-têtes HTTP qui permettent aux serveurs de servir des ressources aux domaines d'origine autorisés. Les navigateurs prennent en charge ces en-têtes et respectent les restrictions qu'ils établissent.

Exemple : supposons que votre site soit http://my-cool-site.com et que vous disposez d'une API tierce sur le domaine http://third-party-site.com , à laquelle vous pouvez accéder via AJAX.

Et supposons qu'une page que vous serveur de my-cool-site.com a fait une demande à third-party-site.com. Normalement, le navigateur des utilisateurs refusera les appels AJAX vers tout autre site autre que votre propre domaine / sous-domaine conformément à la politique de sécurité de même origine . Mais si le navigateur et le serveur tiers prennent en charge CORS, les choses suivantes se produisent:

• Le navigateur enverra l'en-tête HTTP suivant à third-party-site.com

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

• Si le serveur tiers accepte les demandes de votre domaine, il répondra avec l'en-tête HTTP suivant:

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

• Pour autoriser tous les domaines, un serveur tiers peut envoyer cet en-tête:

  Access-Control-Allow-Origin: *

• Si votre site n'est pas autorisé, le navigateur générera une erreur.

Si le client a des navigateurs assez modernes qui prennent en charge CORS et que votre serveur tiers prend également en charge CORS , vous pouvez certainement y aller avec des modifications mineures à votre code.

J'ai trouvé une belle explication sur CORS , sur laquelle vous trouverez également une autre façon de procéder: JSONP . Mais JSONP nécessiterait une bonne quantité de modifications de votre code.

Pour faire une demande XMLHttpRequestCORS, il vous suffit de l'utiliser dans Firefox 3.5+, Safari 4+ et Chrome et d' XDomainRequestobjet dans IE8 +. Lorsque vous utilisez un XMLHttpRequestobjet, si le navigateur voit que vous essayez de faire une demande interdomaine, il déclenchera de manière transparente le comportement CORS.

Voici une fonction javascript qui vous aide à créer un objet CORS multi-navigateur.

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;
}

Puisque vous dites que «la plupart des navigateurs ont bloqué l'utilisation de XML entre domaines», je suppose que votre serveur tiers pourrait ne pas prendre en charge CORS. Ensuite, vous devez trouver des approches alternatives.

Pour des raisons d'évolutivité, je voudrais garder la charge du serveur aussi petite que possible

Je pense que cela indique plus ou moins la réponse. Le fait de fournir ou non des données prétraitées au client dépend principalement:

1. la différence en matière de trafic
2. l'impact sur les performances du traitement
3. l'impact d'un format de données différent sur le client

Si le XML est relativement petit ou s'il n'y a que quelques demandes, il peut être judicieux de simplement le transmettre au client et de l'oublier. Il en va de même lorsque les données prétraitées constituent toujours une grande partie des données d'origine, ou si le client n'est pas en mesure de tirer grand profit d'un format de données différent (par exemple JSON).

Cependant, si le client a du mal à traiter un grand ensemble de données XML, ou si le client n'a besoin que d'une petite fraction des données XML d'origine, il peut être judicieux d'effectuer un prétraitement côté serveur.

À la fin, il est plus facile de faire évoluer un serveur que de faire évoluer un client / navigateur ou la bande passante disponible. Pour le mettre dans une phrase, cela dépend de l'endroit où se trouve le goulot d'étranglement dans le système.

Mon choix serait de mettre en cache et de compresser (jeter les informations inutiles) et les résultats gzip dans le navigateur client, votre option # 2 . Parce que les navigateurs ne sont généralement pas des processeurs haut de gamme et que les lignes réseau du serveur au navigateur sont de capacité limitée. Je parle de clients mobiles . Si vous ne prévoyez pas de prendre en charge les clients mobiles, choisissez ce qui est plus simple, par exemple certainsGoogle:CORS proxy