CODEWITHSUNDEEP
xmlajax
Alf
Alf

Reputation: 33

Using XML for Ajax response vs normal HTML

Can anyone give me a good reason why I would want to use XML as a response from an ajax request other than organizational purposes and ease of readability? I'm trying to be as secure as possible, and I'm not sure if using XML is more secure or simply better practice? Most sources provide reasons to use XML that don't interest my security concerns.

Upvotes: 2

Views: 227

Answers (3)

Noah Mendelsohn
Noah Mendelsohn

Reputation: 11

Assuming you are indeed comparing XML to JSON, then in addition to the good advice you've already gotten from Mads and JBone:

In most cases, where you're dealing with the sorts of data items that neatly map to typical programming language variables and structs, then JSON tends to be more convenient. Where XML has much better power is if for some reason you are conveying marked up text, or what we might informally call "documents". An example I often use is of an insurance company:

  • If you're returning lists of policy holders, their addresses, and the amount of their insurance coverage, either XML or JSON will work, and JSON is likely more convenient (and may have fewer same origin issues).

  • If you're trying to return the text of an actual insurance policy, with section headers marked with tags, then XML's so-called mixed content capability (the ability to have tagsin the middle of a run of text like <tag>this</tag>) is much more appropriate than JSON.

  • If you want to combine data lists with document templates (e.g. a template for an insurance policy, with place-holders for the name of the insured and the amount of coverage), then using XML for both your data and your template can enable use of languages like XSLT or XQuery to combine them

All of that said, for at least 95% of what people are doing with Web apps today, JSON is a reasonable choice.

Upvotes: 1

Mads Hansen
Mads Hansen

Reputation: 66723

If you provide a response as XML it helps restrict who can request the data from a browser, due to same origin policy restrictions.

If it is an XML response, your AJAX calls need to be true Asyncronous JavaScript And XML that are restricted to requesting information from the same domain that the webpage is hosted from, rather than dynamic script elements fetching JavaScript which can request data from anywhere.

Providing a JSON interface opens the door for people to use JavaScript to generate dynamic <script> tags and fetch the JSON data that you expose from anywhere, regardless of where the code "lives".

If a person has an active session and is authenticated to your webapp, a malicious agent could use their webpage (or inject malicious JavaScript into anyone else's libraries that might be included on a webpage) to fetch the data from your service, parse the information in the browser, and then send to their own services.

If you expose your data as XML, they would need to your the XMLHttpRequest Object to communicate with your interface from a browser (without enabling security exceptions) and would only be able to interact with the site that the webpage lives on.

Upvotes: 0

JBone
JBone

Reputation: 3203

I think this depends on where you are returning to. Usually if returning to javascript (which i am assuming here) is is beneficial to re turn using JSON format. JSON is simple and lightweight. There are methods in .NET and also jQuery that can parse and serilize/decerlize this.

jQuery.parseJSON( "json" )

this will parse a JSON string to a JQuery object

JSON.stringify(your_object)

this will parse an object into a jquery string you can send up to an ajax call

using System.Web.Script.Serialization;
IList<NewFee> ExistingNewFees = new JavaScriptSerializer().Deserialize<IList<NewFee>>(ExistingNewFeesJSON);

this snippet illustrates deserlizing a json string into a generic list type of a predefined class.

Upvotes: 2

Related Questions