My company has thousands of existing xml web services and is starting to adopt AngularJs for new projects.
The tutorial over at http://angularjs.org/ uses json servi
I created a service named HttpService
having a function called getRequestedContent
in which I am using angular http call to my service "http://localhost:8080/showserverstartupinfo" which returns a xml as follows:
<SERVERSTARTUPINFO>
<SERVERNAME>########</SERVERNAME>
<SERVERSTARTUPTIME>##########</SERVERSTARTUPTIME>
</SERVERSTARTUPINFO>
...and I parse the above xml and populate my div with content of xml element.
HttpService.getRequestedContent('/showserverstartupinfo').then(
function(content) {
//successCallback
var xml = content.data;
document.getElementById('serverName').innerHTML =
xml.getElementsByTagName("SERVERNAME")[0].childNodes[0].nodeValue;
}, function(data) {
//errorCallback
});
getRequestedContent function in HttpService(Angularjs) as follows:
getRequestedContent : function(request) {
var url = this.getRootContextPath() + request;
return $http({
method : 'GET',
url : url,
transformResponse : function(data) {
return $.parseXML(data);
}
});
}
I would recommend you to have a xml to json converter. Here is one.
https://code.google.com/p/jquery-xml2json-plugin/
After the conversion, you have a normal JS object where you can use your normal angular directives to parse through them and use them as you want.
I'm finding x2js is working quite well: https://code.google.com/p/x2js/
The client takes in the XML, no need to mess with the angular services. A simple quick conversion and, voila, you have a JSON API that mimcs the XML document. Seems to take care of all the use cases I've run into.
I had the same problem. Ended up making a small module to turn all my XML responses in to a ng.element object.
https://github.com/johngeorgewright/angular-xml
If option 2 is relatively easy for you (like adding one-line JSON conversions in your back-end controllers, for example), then it's probably a good investment, as the JSON is leaner over the wire, far less work on the client side and generally preferred by RESTful API consumers (in case there are other consumers).
Having recently done this kind of work, I'd say the next best path (if option 2 is difficult) would be to use response and request transformers to perform conversions between your XML and JavaScript objects, which is a variation somewhere between your options 3 and 4. The DOMParser object is native code, so it parses XML plenty fast. Transforming the XML DOM to JavaScript objects and generating XML from JavaScript objects are both fairly straightforward recursive algorithms. This approach decouples all of the rest of your client-side code from the back-end representation, which would not be the case if you went with your option 1. Such decoupling would allow you to make direct use of a JSON-based RESTful interface, should such an opportunity arise.
Selecting any option that involves JSON/JavaScript objects will often involve dealing with impedance mismatch issues like XML attributes, XML collections vs. JS arrays and XML mixed content representation. If your data models are simple enough, or you don't mind living with the solutions provided by out-of-the-box transformers between XML and JSON (e.g., redundant object containment, numbered text properties to represent disjoint text mixed with elements), then this may not be an issue for you. Otherwise, there are opportunities for customizing transformation behavior at either end of the request imperatively (though sadly not declaratively, as far as I've seen).