> If you just need a light-weight API that is only ever going to be REST orientated, then use JSON.
I disagree with that assertion. There is nothing open Web can possibly gain by adopting JSON for its APIs.
In a heterogeneous ecosystem, much like Web is, it'd be much more productive to have a typed, extendible and validatable format like XML.
Last but not least, what does make XML ill-suited for any ‘lightweight’ APIs? Atom fits nicely with REST and is quite lean. There's hardly anything JSON can offer, to my knowledge, that could be any lighter or more robust.
Well that's the point, isn't it? XML unifies various independent ecosystems. At the very least, if defines such essential things like data and time representation formats, whereas JSON doesn't even attempt to do that.
But then XML goes further and provides you with a contract. Now anyone can write their independent implementation and test it (validate it) to that contract. This is what Web was about in the first place. You can use any technology imaginable, any language imaginable, but in the end you are delivering to common format, HTML+JS.
Now that this is insufficient, the natural evolution would be XML and REST. JSON, however, is a liability. I believe it is, in fact, the next IE6!
> In a heterogeneous ecosystem, much like Web is, it'd be much more productive to have a typed, extendible and validatable format like XML.
XML is not any more or less typed, extendible or validatable than JSON. They are both serialisation formats that make you put data into their own structure, a tree with attributes for XML and lists and dictionaries for JSON.
Exactly two types exist in XML: tree and text. And exactly six types exist in JSON: list, dictionary, string, number, boolean and null.
What XML has that JSON doesn't is a solution for automating validation called XML Schema.
XML was, in fact, designed with all those things in mind. Here is the 2nd design goal and its rationale, from 1996 draft specification[1]:
> 2. XML shall support a wide variety of applications.
> No design elements shall be adopted which would impair the usability of XML documents in other contexts such as print or CD-ROM, nor in applications other than network browsing. Examples of such applications include:
> validating authoring tools
> batch validators
> simple filters which understand the XML document structure
> normalizers
> formatting engines
> translators to render XML documents into other languages (e.g. RTF, TeX, ...)
It should also be noted, that XML included the DTD specification from the very beginning. Although much different from the current state of affairs—still no namespaces and not quite the flexibility of XSD—it's nevertheless an important distinction.
As you might imagine, such core concept were further developed, which resulted in the 1.0 spec of XML Namespaces[2] (called xml-names at that time) and with XSD soon following suite.
To say that JSON and XML are anything alike is unfair. As JSON's own RFC states, it was meant to be merely:
> JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript.
No concern is given for its interoperability between vastly different environments, nor did it try to position itself as a replacement for XML, which would surely be known to its creators at that time. Subsequently, there's no mention of validation or extendibility.
Of course the concept of XML Namespaces is well unique to XML. Even the JSON Schema[3], does not introduce anything similar, but just merely provides an optional meta-document, describing—or should I say—hinting, about how the document may look like:
> It is acknowledged that JSON documents come in a variety of structures, and JSON is unique in that the structure of stored data structures often prescribes a non-ambiguous definite JSON representation.
> Cumulatively JSON Schema acts as a meta-document….
The JSON schema is of course still a draft today, and has received almost no adoption[4] from the community.
This should be, however, obvious, given the fact that it took a whole 4 years for JSON Schema to emerge (such a long time in the noughties), suggesting just how non-essential value it must hold for its users.
What I'm honestly afraid, is that JSON Schema will ultimately get our attention. But neither because we will seek it for its technical brilliance, which it hasn't got, nor because we will seek it for its user-friendliness, which is unimpressive, but because we will be desperate.
After enough developers will get seduces by the carelessness of JSON—“blimey, I don't have to think at all, and it's endorsed by some bloggers”—we will embrace JSON Schema and, surely, invent a whole novel ecosystem, just to deal with the mess, that such ‘fuck open Web, I'd rather just output garbage, because it is more convenient right now’ attitude could only bring.
I disagree with that assertion. There is nothing open Web can possibly gain by adopting JSON for its APIs.
In a heterogeneous ecosystem, much like Web is, it'd be much more productive to have a typed, extendible and validatable format like XML.
Last but not least, what does make XML ill-suited for any ‘lightweight’ APIs? Atom fits nicely with REST and is quite lean. There's hardly anything JSON can offer, to my knowledge, that could be any lighter or more robust.