|
Hmmm...
This may be getting philosophical, but I disagree on the JSON-vs-XML thing.
JSON is a format whose sole purpose is to represent data structures in a format that is both machine-readable and (somewhat) human-readable.
XML is a format that is meant to represent information in a machine-readable format, which is human-readable as well.
Everything that can be represented in JSON can be represented in XML as well. But the opposite is not true, simply because XML is much more expressive than JSON.
Before this gets out of hand: XML is indeed an extremely "noisy" way to represent things. The actual information tends to get buried inside the representation, simply because the metadata occupies much more space than the actual data. There have even been scientific papers showing that a very efficient compression algorithm for XML simply considers the differences between the instance and its schema definition.
I know about these, and I'm dealing with XML (SOAP, in particular), in everyday life. I have been cursing about SOAP and XML almost every day. But the point is: just like REST is not an alternative to SOAP, JSON is not an alternative to XML. Both lack the expressiveness that XML provides. In other words: they are not able to provide a concise description of their own data (format), which is essential for automated communication. And as much as XML drives me up the wall at times: A SOAP webservice can clearly describe itself, its interfaces, and its data structures, using WSDL. WSDL is based on XML Schema, which can actually "define itself", being based on XML.
There is nothing wrong with using JSON for simple tasks, if you know the data format beforehand. And of course, there have been atrocities like simple configuration files being "encoded" in XML. XML *can* describe pretty much everything (including itself), but that doesn't mean that XML should be used everywhere. Agreed. However, I disagree to condemn XML entirely. There are valid reasons to employ it, especially when things *do* get complex.
|