Tuesday, October 20, 2015

Web: JSON or XML?

Originally published 

Mon 8 Dec 2008

Editors Notes
Some thinking out loud on the topic of portability for complex data objects.  To this day, I more prefer JSON for UI programming and XML for integrated data delivery.  

Original Post


The question, JSON or XML, is not posed so much as a turf war inducing prod but as an examination of propriety. When would you use either and what are some favored methods (and frequent pitfalls) worth discussing?

In my brief experience with these two data encapsulation formats, I've learned things are never as easy as they appear. With XML, you have schema and validation concerns. With JSON you have validation in the sense that it must be valid JavaScript. With both you have to have a way to communicate the meaning of the content to the consumers, either via a description file (like a WSDL) or through documentation.

Bandwidth concerns really aren't so much a concern as they were in the past. The fact that you're loading the data as a message and not the entire page makes any delay small in either case, but likely smaller for JSON as there is very little space wasted on markup. But this does raise the question of security. An easy way to access JSON data is to use an eval statement. Unless you're the only consumer, e.g. you don't plan for others to use it, you would have a difficult time convincing folks to use your service. It goes without saying (which is my way of saying I'm going to say it) that you should never eval or use a hosted script you don't own or explicitly trust.

So, presently, it seems the arguments for and against each balance out. The only real effort is coming up with a schema and designing your object. In that case, JSON is the easier choice though there are plenty of tools that make it a simple task for XML as well. Processing time likewise could be considered to be function of the complexity and size of the message.

Horses for courses, in the end. If it's a small bit of data, JSON is probably the quickest way to get rolling. If it's going to be a complex affair with public exposure or you have standards based concerns (there is presently little in the way of adopted JSON standards) you probably are warranted the minor extra effort and thought that goes into XML.

I will say, though, XML requires far more planning and forethought than JSON. So again, here we have not so much a detraction for XML as a qualifier for when to use it. Robust systems designed to scale well should probably use XML. Small systems (or small components) with little or no plan to ever expose the functionality are probably quickest served by JSON.

As a side note, I found it interesting to know that the State of Ohio has totally disallowed AJAX for the moment as it presents "too much surface area" for potential attacks. I found that to be an interesting statement, but these are the folks that are paid to be paranoid and keep our private data private, so I take it with some authority. If you found yourself in this situation, JSON will be harder to implement without a special server component to evaluate JavaScript server side (something that is becoming more common by degrees) and XML (readily consumed by many server side languages) becomes the clear choice. This brings up another instance where you'd want to use XML - where the data provided must be consumable by a server based service. The abundance of XML parsing tool kits for server side processors makes it a defacto standard in this scenario.
Any one have strong feelings one way or the other?

No comments:

Post a Comment