Comments on: JSON Web Services – the XML JSON debate further ahead

By: nitinpai

nitinpai — Sun, 22 Apr 2007 09:41:46 +0000

Hi pascal,

JSON is data centric and XML is meta data centric.
JSON and XML are never intended to be read by humans. I understand your concern where you mention the fact if JSON was used in Ant. But tell me, do you ever transfer Ant Build Files to any requesting service?

I want to highlight the case of transfer of data and NOT on configuring meta data. Of course XML is far better but only while configuring meta data. If you use XML for heavy duty data transmission your bandwidth gets chocked up. Such situations can be handled by some slternative mechanisms like JSON. And here I presume you do the data transfer with API’s and not hand code the JSON fragment before transfer.

Finally it all boils to the case of data transmission and is never the case of readability when choosing a communication medium. Ever read an RMI object?

By: pascal

pascal — Sun, 22 Apr 2007 09:28:42 +0000

If you want human readbility, xml makes sense. Try reading a json file and finding what data ends where can be confusing….

Like you mentioned the use of xml in config files for ant; think if they were in json, we would never find what ended where.

Anything that can be written in xml can be written in json. Your choice should be decided by who is going to read your file.

If your code is going to be read only by a parser(the java-script eval or any other) json does a nice job. It is easier to parse. It is much more smaller in size. Can save a lot of unwanted data going around. I have noticed that sometimes the metadata doing around in xml is more than the read data transfered… a huge overhead. Definitely not needed if your code will never be seen by a human.

By: Alexander Botero-Lowry

Alexander Botero-Lowry — Mon, 02 Apr 2007 06:49:19 +0000

Well, a RESTful web service has a number of meanings to a number of people and a number of things. It is true that HTTP is RESTful in that it is designed to allow for transitions in state. Something like XML-RPC doesn’t really take advantage of this part of HTTP’s design. RESTful apis usually look something like

GET /user – list of users
PUT /user – Add a user
GET /user/1 – info about userid 1
DELETE /user/1 – Delete userid 1
POST /user/1 – Update info for userid 1

Instead of providing method calls for this. There are some great pages explaining why this is better then a SOA style web service or an XML-RPC one. I particularly like this one:
http://duncan-cragg.org/blog/post/getting-data-rest-dialogues/

By: nitinpai

nitinpai — Mon, 02 Apr 2007 06:38:41 +0000

I have seen this many time people referring to RESTful services, as you did. I believe that HTTP is a REST based protocol and web services have been implemented on HTTP only. But why is it so that people sometimes refer to the web services as RESTFUL services. Isn’t REST inheritantly applicable to the term “web services”. Or is there something like non RESTful services?

By: Alexander Botero-Lowry

Alexander Botero-Lowry — Mon, 02 Apr 2007 05:59:25 +0000

I already use JSON for all of my web application APIs. They accept data encoded with JSON and return a result encoded with JSON. They’re not method call oriented but rather RESTful, but I’ve seen some convincing RPC implementations using JSON as well.

By: nitinpai

nitinpai — Mon, 02 Apr 2007 05:08:57 +0000

Hi Alexander,
I have read about the XML JSON debate in the link you provided.
I havent tried JSON myself though.

What you say is correct but in my opinion if JSON is an alternative to XML then probably we can use it in web services in future for all its good purposes.

By: Alexander Botero-Lowry

Alexander Botero-Lowry — Sun, 01 Apr 2007 21:55:50 +0000

Err… JSON is a subset of Javascript objects (boolean, number, string, array, null, undefined, and object [but only with attributes of the above types]) which is serialized into a string and can be directly evaluate by Javascript.

Thus, “Hence it does not require parsing libraries in an application as XML does,” is not exactly true. In Javascript that’s the case since you can either use eval() directly, but in other languages you need a library to deserialize the JSON input. For example if you try to eval(‘true’) in python you’ll get:
>>> eval(‘true’)
Traceback (most recent call last):
File “”, line 1, in ?
File “”, line 0, in ?
NameError: name ‘true’ is not defined

The key reason to use JSON is that, being an object notation, it was designed for interchanging data types, whereas XML was designed as a structured format for data and has ‘recently’ became a system for doing data-type interchange. These issues are discussed on the JSON website: http://www.json.org/xml.html