Previously I used XML soap for data exchange in my web services, But switched to json for another project. Now I cant seem to find a reason to go back to XML, primarily because of the response size difference for large objects.
In what case would you need to use XML over json for web service response?
legacy clients that does not support JSON. otherwise it's a no brainer.
JSON is easier to parse, more economic in size and easier for people to read (if formated).
I would never use XML unless it is mandated by the other end of some service I want to consume. JSON is simple, readable and flexible. The "readable" factor makes a huge difference when things go wrong and you have to crawl through logs to sort out the mess.
Taken from this link (I agree with the general idea proposed here):
Use JSON · Seems easy to me; if you want to serialize a data structure that’s not too text-heavy and all you want is for the receiver to get the same data structure with minimal effort, and you trust the other end to get the i18n right, JSON is hunky-dory.
Use XML · If you want to provide general-purpose data that the receiver might want to do unforeseen weird and crazy things with, or if you want to be really paranoid and picky about i18n, or if what you’re sending is more like a document than a struct, or if the order of the data matters, or if the data is potentially long-lived (as in, more than seconds) XML is the way to go.
Good question. JSON is undoubtely more easy to use in some scenarios, but you should consider that cannot be validated, and has no namespaces. On the other hand is definitely lighter than XML and for things such as javascript and ajax communication gives you a lot of flexibility.
You can take a look here:
http://www.infoq.com/news/2006/12/json-vs-xml-debate
http://ajaxian.com/archives/json-vs-xml-the-debate
It depends on what type of client will be connecting to that web service.
If you plan to contact the web service from inside a browser a'la AJAX calls from Javascript, then JSON is the hands-down winner because it essentially is the serialization of Javascript objects. This property of JSON makes it a much better fit for client-side scripting in Javascript. JSON data can be regurgitated right into living, breathing Javascript objects without much hullabaloo.
XML and JSON were designed for two distinct purposes. XML originated as a way to give semantic definition to text in documents. JSON on the other hand is specifically for serializing data structures.
Both can do what each other can do, but those fundamentally different base design rationales are I think evident in how you work with each type of markup.
True, XML can represent data structures, but an example of describing structures like empty arrays in XML shows off how JSON is much better at describing data structures.
JSON on the other hand is woefully mismatched to describe semantic meaning behind text in documents, which is where XML excels (think HTML).
No easy answer. The requirements of your connection client and the type of data you need to serialize should drive the decision between XML and JSON.
JSON for web services answering in-browser callbacks, and XML for, well, XML for when, well, hmmm. :-)
Actually I don't understand the JSON vs. XML contradiction. We happily use both in parallel:
JAXB is capable of reading/writing objects from/to XML. DWR is capable of reading/writing objects from/to JSON. These "objects" are the same objects.
So you can actually have both XML and JSON on the same data model.