views:

81

answers:

2
+5  Q: 

Root Nodes in JSON

I'm tasked with defining communication between two web apps. I've decided to use JSON for this. How common is it to have a root node in the JSON?

Let's say we have a car object. This is the JSON with "Car" being the root node:

{"Car": { 
  "Make":"Mustang", 
  "YearBuilt":"1999"}}

So now let's say I have a Tire object and since we are standardizing on having root nodes, this one also has to have it.

{"Tire": {"Make": "Brirdgestone", "Size":"15"}}

Integrating the tire object JSON into the original Car object shows how unwieldy it could be.

{"Car": { "Make":"Mustang", 
"YearBuilt":"1999",
"Tires": "[{"Tire": {"Make": "Brirdgestone", "Size":"15"}},
{"Tire": {"Make": "Brirdgestone", "Size":"15"}},
{"Tire": {"Make": "Bridgestone", "Size":"15"}},
{"Tire": {"Make": "Brirdgestone", "Size":"15"}}
]}}

So serialized in PHP, the make of the first Tire would be $object->Car->Tires[0]->Tire->Make. There's that extra Tire level there because of the root node.

If Tire did not have the root node the code could be a lot slimmer.

{"Car": { "Make":"Mustang", 
"YearBuilt":"1999",
"Tires": "[{ {"Make": "Bridgestone", "Size":"15"}},
{"Make": "Brirdgestone", "Size":"15"}},
{"Make": "Brirdgestone", "Size":"15"}},
{"Make": "Brirdgestone", "Size":"15"}}]}}

In PHP, there's less confusion because there's less redundancy: The make of the first tire is called by $object->Car->Tires[0]->Make

Is there anything bad by not having a root node? I like having the root node because it acts likes a class name, but needless levels bug me a lot and will make traversing more complex.

+4  A: 

I'd omit both root nodes, Tire and Car.

Keep in mind that JSON's primary use is transfering objects over the network in a compact format. There is no real other usage beside this. You want to work with the data the JSON encodes and by adding the root nodes, you are creating empty container objects with no real identity and purpose. When omiting the root nodes, you get

$car->tires[0]->make

and in JS you'd get

car.tires[0].make

This is much clearer and represents the object much better. Remember, this is what you will have to work with. Sure, you could use some sort of JSON mapper that maps how objects should be serialized and that result in the above objects, but that's a lot of extra effort and not worth it imho.

If you want to have the class name in the JSON, just make it a property, e.g.

{ 'klass': 'Car', 'make': 'Mustang', 'year':1999 }
Gordon
I agree. Root nodes would just make the consuming app code unnecessarily verbose.
Steve
Cool, thanks a lot. I thought of one area where it would be important. If the JSON mirrors and XML document, you should add one at least on the main object because in XML, you need a root element.A colleague also pointed out that it's important for JSONP callbacks and would be a better structure if I was creating an API. For example, Yahoo and ebay APIs wrap everything around a ResultSet node. This allows parsers that care about types to bind the ResultSet to an object type.
Well, I am sure you can think of UseCases where it might come in handy, but then again, whenever I used JSON in my apps, I had callbacks that knew how to handle the data they received, e.g. example.com/cars/find/id/123 would return car data and my callback would create them.
Gordon
A: 

@Gordon makes good points. However, I like to use AOP with AJAX messages to intercept messages to and from the server. These interceptors add to each message a timestamp and on messages sent from the server a status flag (fail, exception, success, whatever...). As you likely surmised, I put use a root JSON node for the payload, status, and timestamp.

The status flag sent from the server can be examined in one function (aspect) on the front end and all exceptions handled in one place. When the server fails for a reason other than an exception, the aspect/advice allows the data to be passed to the AJAX initiator.

Upper Stage