Si l'option 2 est relativement facile pour vous (comme l'ajout d'une ligne JSON conversions dans votre back-end contrôleurs, par exemple), alors il est probablement un bon investissement, comme le JSON est plus maigre sur le fil, beaucoup moins de travail sur le côté client et généralement préféré par les API RESTful les consommateurs (dans le cas où il y a d'autres consommateurs).
Ayant récemment fait ce genre de travail, je dirais que le meilleur chemin (si l'option 2 est difficile) serait d'utiliser la réponse et la demande des transformateurs pour effectuer des conversions entre XML et les objets JavaScript, qui est une variante quelque part entre vos options 3 et 4. Le DOMParser objet est en code natif, donc il analyse XML beaucoup rapide. La transformation du XML DOM de JavaScript objets et de générer un document XML à partir d'objets JavaScript sont à la fois assez simple d'algorithmes récursifs. Cette approche dissocie tout le reste de votre code côté client à partir de la fin de la représentation, qui ne serait pas le cas si vous êtes allé avec votre option 1. Un tel découplage vous permettra d'utiliser directement un basé sur JSON interface RESTful, si une telle occasion se présente.
En sélectionnant l'option qui consiste à JSON/JavaScript les objets impliquent souvent de traiter avec les différences d'impédance des questions comme les attributs XML, XML collections vs JS tableaux et XML contenu mixte de représentation. Si vos modèles de données sont assez simples, ou vous n'avez pas l'esprit de vie avec les solutions fournies par out-of-the-box transformateurs entre XML et JSON (par exemple, redondant objet de confinement, numérotés de propriétés de texte pour représenter disjoints texte mélangés avec des éléments), alors c'est peut-être pas un problème pour vous. Sinon, il existe des possibilités de personnalisation de la transformation de comportement à l'une des extrémités de la demande impérativement (mais malheureusement pas de façon déclarative, autant que j'en ai vu).
