1 in 5 APIs Say "Bye XML"

Adam DuVander
May. 25 2011, 08:00AM EDT

Simplicity wins again. Much as there are more RESTful APIs than SOAP, XML-RPC or other protocols, JSON is gaining ground on the old favorite, XML. Last fall we said JSON is the developer's choice and therefore it's becoming the API provider's choice, too. XML still wins overall, but more new APIs use JSON than XML. Of APIs we've seen in 2011, 20% only use JSON, meaning 1 in 5 are saying goodbye to XML.

JSON's simplicity means easy parsing into most languages, which XML can make a chore . It's especially easy to interpret JSON in JavaScript because it is JavaScript. When APIs support JSONP, developers can make calls to APIs directly from the browser, when appropriate.

JSON, without opening and closing tags, is lighter weight, which both developers and providers appreciate. There also isn't the overhead of namespaces and schemas

The trend in our API directory is quite apparent: XML is on the decline. But is that a good thing? Enterprises may prefer XML because they have the tools in place to support it. Also, much of the reason XML is complex is that it's trying to solve complex problems of data interchange by providing a meta language to describe the data.

As JSON gains wider adoption, it will face some of the same issues XML tackled over the last decade. The JSON Schema project is one example of standardization happening within JSON. Will developers continue to choose a more complex JSON? Will providers return to XML for the tools it has to support complexity?

Adam DuVander -- Adam heads developer relations at Orchestrate, a database-as-a-service company. He's spent many years analyzing APIs and developer tools. Previously he worked at SendGrid, edited ProgrammableWeb and wrote for Wired and Webmonkey. Adam is also the author of mapping API cookbook Map Scripting 101.

Comments

Comments(47)

I definitely prefer JSON. It's generally simpler, which is great from the programmer's perspective. There seems to be a by-product of its simplicity in that it seems less likely to be wrong/invalid, which isn't always the case with XML.

There may be a bit of a skew to this as well. A new project to use a new technology on an old problem doesn't negate an existing project that uses the old technology on the old problem. Someone wanting to address it with XML will latch onto an existing project while someone wanting JSON will have to start a new project.

I do find it funny how these technologies are new, old, simple, and overcomplicated, depending on who's talking. It hasn't been five years since I've seen XML billed as the new, simple way to do everything and watched Microsoft, Apple and everyone else shove malformed XML into every nook and cranny of their applications, with particular zeal in putting it where it didn't belong. Now JSON is new and simple and XML is old and complex, yet if you solve the same problem with each, they rise to the same level of complexity, and XML is about 3 years older than JSON, it was just more quickly adopted because of its SGML roots.

In short, this is classic Developer's New Toy syndrome. Nothing better or worse inherently to the technology. No time savings that stand out on balance when all things are considered. No logic to how it's applied over the alternative. But it's visually more like what the vocal crowd is working with now, so it's "simpler", and anyone who points out the problems with Javascript that it inherits is a curmudgeon.

Neither XML nor JSON is appropriate for what they're mostly used for. They both claim to be human readable, but the average user is just as lost looking at them as they are a hex editor's screen. I can still encode, transmit and decode CSV faster than both, and write a parser in half the time. And for what reason are we making "human readable" this data that is sent between computers, never to be read by human eyes? If you're hand-coding XML/JSON or reading it, you either are playing around for your own amusement, or you're debugging, which could just as easily use a tool. The only reason 90% of developers use XML or JSON is because the tool they use or the services they connect to require it.

I think they both have their places. As a previous commenter noted, XML is very suitable for complex data interchanges whereas json is not so suitable for those situations. On the other hand, XML is WAY overkill if all you need to do is pass some poco's around from client to server and vice versa. The overhead of parsing said XML into the poco is a barrier enough and that's without taking into account all the complexities of XML, namespaces, validation and such. Json is a simple eval way from hydrating poco's passed across the wire.

JSON is not expressive at all; not to anybody but a developer and it lacks a means to encapsulate, describe and document meta data on a file system. When and if it is made to try to do so it will be even worse than XML.

nuno

It's not a matter of preference, it's a matter of right tool for the job. For APIs JSON makes sense, for mixed content XML makes sense. For API that serve mixed content - shaky waters but you are probably better off with XML?

[...] at hand is the evolution of the web. APIs are available for so many social applications now and those applications are moving towards JSON as the data format. There is also a very good reason for this. Many applications are focused on [...]

I'm 43 and I prefer JSON, so I'm not sure age has much to do with it.

Perhaps it's a MS / corporate IT view vs a web view?

XML particularly in SOAP form just becomes over verbose for me, then you get into the whole discussion about when to use attributes and when to use elements and often have to deal with others choices, JSON doesn't seem to have that issue.

JSON and XML do very different things even though they are both equally expressive when used at a structural level (XML does allow markup, and JSON is better for unnamed stuff). For instance, in one of my systems, the config and some templating are in XML, while JSON moves the data back and forth between the client and server. That plays to the strength of each.

I don't think XML is dying, but it was getting over used there for a while...

Paul.

pico

Stewart made an interesting point about descriptors (wsdl). But I guess that's too corporate to be cool and hype.

There are other advantages of XML as pointed by other people in here. JSON has its own advantages too, which everybody seem to be talking about at the moment for some reason.

The title of this blog post doesn't resource to a good choice of words. "Goodbye XML", as if the two technologies would be two absolute competitors. That doesn't make sense. Their purposes overlap a great deal, no doubt, but they are still distinct in many aspects.

See you within 2 years or so for the "goodbye JSON" festival, when all the cool kids have moved to some other format.

[...] at hand is the evolution of the web. APIs are available for so many social applications now and those applications are moving towards JSON as the data format. There is also a very good reason for this. Many applications are focused on [...]

mattp

What is there to be so giddy about? The fact that there are less options to work with? Does the fact that Facebook and Google ONLY return JSON really affect the world at large? No. I'm an advocate of options...the more the better.

I guess what I'm trying to say is let the JSON fan-boys use JSON, but keep XML as an option (like the grown ups: YDN, Microsoft, all Govt Open Data APIs, etc.

..and yet on the other hand I have to disagree with James in the previous comment. XML is blindingly obvious to read, even for humans. XML is no more or less likely to be wrong, unless while coding you're susceptible to bouts of typing "I hate XML" at random points. Either your code is correct or it's not, regardless of output format.

What would be interesting is seeing if there's a correlation developer age and preferred choice of output format. Maybe the young 'uns prefer JSON ?

I think one needs to question where these results come from. I suspect there's a huge number of APIs used internally in organisations and products that are not exposed publicly, and I'm willing to bet that a large proportion of these are XML / SOAP based.

There are many advantages of JSON in a RESTful style, but there are many APIs that do use JSON and do not follow a RESTful approach (not necessarily a bad thing, just an inconsistency). Also JSON does little to enforce a contract in terms of the data types used. On a similar note, XML based web services with exposed WSDL documents present an excellent standardised interface which developers can look at for an impression of the features available and use automated tools to test and generate code from the web service. It is very much up to the developer of a JSON / RESTful API to document how it should be used and the format of the interaction with the API.

For me, the most important feature of XML based services is WSDL (and the ability to generate it from the code that most platforms have). In my view WSDL essentially documents the web service itself. Perhaps WSDL with REST will become more popular in the future?

I think it is indisputable that JSON reduces the barrier of entry for programs running on less powerful mobile platforms or written for environments which do not have feature rich and easy to use XML processing libraries readily available.

While XML may be overkill for for exchanging simple structured data, it has lots of useful features for creating more complex resource representations. I would not write off XML yet.

@hadron: Whu? Why would you need anything as complex as XPath for JSON?

var jsonObj = {

"foo": "bar",

"arr": [0, 1, 2, 3, 4, 5],

"obj": { "hello": "world", "val": true }

};

jsonObj.foo => "bar"

jsonObj.arr[3] => 3

jsonObj.obj.hello => "world"

In JSON, there is only one tree where children are indexed by strings (objects) or implicitly by numbers (arrays).

XML has some serious advantages, since you can easily mix-and-match XML documents using XML technologies that are ubiquitous. We have yet to develop industry-grade variants of XPath, XSL, and so forth for JSON.

As those replacement technologies appear, the need for XML will dwindle accordingly, and it will settle into the niches it SHOULD have been used in. Ten years later, the same will happen to JSON, as the "me too" craze slowly realizes JSON it just as much of a pain in the ass and is largely reinventing wheels.

At the very least, you could quote the sources for your information. Where are you compiling these stats from? You mention the "APIs we've seen", but where have you seen these APIs?

@Andy Davies

I'm 28 and I prefer XML, so yes you're right, age is not really a factor just a matter of personal preference.

@Tool

Yes, I've done that with both JavaScript and Flash and its really not that bad. SOAP sucks in alot of ways, yes, but has a few useful if not redeeming features. Can you point a tool at a JSON endpoint and magically get runnable code to implement it? Not yet... so mainly WSDL makes SOAP usable, which Stewart Sims already mentioned. Other benefits are WS-security and some (but definitely not all) of the WS-* standards. Obviously I wouldn't want to call SOAP from the browser for huge amounts of data but it definitely is useful in some cases, like synchronous requests for mission-critical data submissions or asynchronous background processes (WebWorkers in HTML5 will make this much more pratical since we won't have to wait in the UI at all for data to be passed back and forth).

Obviously it makes sense to learn how to work with both, since each have their valid use cases. I prefer JSON for some specialized tasks such as frequent bursty-data directly to a web app, while I prefer XML overall for most other cases but its main use cases for me are in use for application configurations, deployment, validation of data and any situations where strict typing is useful (i.e. passing a DateTime object, which can have almost an infinite number of serializations in JSON but with XML just one is valid using XML Schema's dateTime, and how to format it is specified by a global panel of super geeks lead by W3C, including the founder of the web Tim Berners-Lee).

Time will tell what the future holds but take a look at the Linked Open Data (LOD) movement which has largely gone on off ProgrammableWeb's radar. The Linked Data cloud is exploding, mostly with RDF/XML data:

http://www.readwriteweb.com/cloud/2011/01/the-concept-of-linked-data.php

If you tally up the total amount of data in the many XML variations out there, I'm sure it eclipses JSON. HTML itself is XML when its well-formed, so if people would just write bloody valid code the entire web would be a data graph not just separate unrelated documents... but that's another story!

Last but not least lets not forget Semantics though. With namespaces, we can differentiate between types of data and instead of just providing textual descriptions of something we can actually programmatically describe an instance of a real identifiable thing, indexed by a URI and referenced against an Ontology or other clear vocabulary. The power of this is immense and if it wasn't important I don't think the creator of the platform upon which we discuss this topic right now would invest so much of his and MIT's time and research energies into it. Also, efforts like RDF/JSON and JSON schema would not exist either.

I've worked on projects where they wanted to use SOAP Web Services or RDF/XML Semantic Web markup and define many complex XML formats, just to accomplish a simple task (to say they did it "semantically") that could have been done in JSON. Likewise, I've worked with some clients who insisted on using JSON when the data they were working with was so complex it took way too many nested structures to model it properly so that the "dotted" access would make it intuitive to parse.

Going forward, I just hope people can make the right call on which technology works best for a given problem and leave their XML and JSON baggage at the door.

Json can be mapped to most dynamic languages' data structures whereas XML needs extremely complicated libraries and nasty memory requirements, any practical and reasonable person would choose the first.

XML/SOAP is a monster created to cash-milk the enterprise and governments, I have seen big companies pay $1000/10000 for each stupid SOAP webservice.

mike

Facebook have also replaced xml with JSON for some of their web service api's as well which should improve site functionality even further and probably senda asignal to others to do likewise.

[...] you to look somewhere else. Like maybe the current trends in web development. As of mid 2011, 20% of the API’s were using strictly JSON. This may not seem that high but when you consider this is up from less than 5% only 3 years prior [...]

Ever tried calling a SOAP service directly from the browser? This is why JSON is popular, it's a simple as that. All this other talk is just people chattering to hear themselves, no?

sandesh

I’ve worked on projects where they wanted to use SOAP Web Services or RDF/XML Semantic Web markup and define many complex XML formats, just to accomplish a simple task (to say they did it “semantically”) that could have been done in JSON. Likewise, I’ve worked with some clients who insisted on using JSON when the data they were working with was so complex it took way too many nested structures to model it properly so that the “dotted” access would make it intuitive to parse.

[...] you to look somewhere else. Like maybe the current trends in web development. As of mid 2011, 20% of the API’s were using strictly JSON. This may not seem that high but when you consider this is up from less than 5% only 3 years prior [...]