Time after time, the web sees the exploit of a technology, sometimes new, other times old, applied in a different context.

This shouldn’t be problematic, although it’s always a pain to explain to fanboys that technology has limitations, because a universal solution would be too general-purpose to resolve all the problems with the most simple and clean approach.

JSON is definitely one of those, hyped, solutions.

New is trendy

You know the proverbial hammer to nail solutions?

Invented the hammer, everything becomes a nail

which means that when the kid has something new, he tries to use it in every context.

I remember the first time I’ve brought my ‘92 ZZR home, because one of the first things my dad said to me was:

I bet when you’ll need to buy cigarettes you’ll go to the tobacconist with it.and he was totally right, although the tobacconist was 500mt far from home.

I was excited everytime I was turning it on, although I knew that using it for such a limited distance was bad because:

I needed to wait some minutes before going, in order to warm up the bike: the result was that, by foot, it took less time to buy my Dianas

if I didn’t wait, every sudden acceleration was a pain for the bike

but I was so convinced, so happy, so dummy that I didn’t care about it.

Don’t piss the audience off

At the NoSQL day of the last week I attended a session about ElasticSearch and MongoDB and blablabla: the topic is irrelevant, while the fact that the speaker asserted that XML should die in favour of JSON is important.

Again, we tend to think that a technology ( JSON ) is the hammer for every nail.

Why XML sucks

Ward Cunningham has a cool section about it and I tend to agree on this: XML sucks in so many ways, we know it.

I basically don’t like some things about XML:

verbosity

not human-readable

slow(er) to parse ( than JSON, for example )

not prone to once and one only

but, as I know nothing is perfect, I’m ok with these drawbacks.

Enters the hero

JSON is a cool format for exchanging data: it’s extremely fast to read and almost human-readable.

A lightweight text-based open standard designed for human-readable data interchange. It is derived from the JavaScript programming language for representing simple data structures and associative arrays, called objects.It wins over XML on a large amount of things, as [David Zuelke states](http://www.slideshare.net/Wombert/xml-versus-the-new-kids-on-the-block-phpbnl11-20110129/43).

Fails the hero

But, as usual, one size can’t fit all.

Consider a JSON object: you have a product with 3 attributes ( name, sku, price ): since you know you are selling a product only in europe, your product’s price is expressed in euros:

12345

{
"name": "Banana",
"sku": 1234,
"price": 24
}

Time goes by and you open an API for online stores around europe: doing this, you let them know about your catalog ( a useful information for price-comparison services, for example ).

Other time goes by and the boss comes into your office telling your company is doing so good that is opening new branches in the united states: so your duty is to update the API in order to show prices both in euros and dollars:

12345678

{
"name": "Banana",
"sku": 1234,
"price": {
"EUR": 24,
"USD": 19
}
}

“Damn”, you think, “the current implementation breaks old clients”: long story short, they expect an attribute but they get an array, and as soon as the consume your service… BOOOM :)

With real attributes and other godness like namespaces XML is a solution for long-term stability: