1 in 5 APIs Say “Bye XML”

Adam DuVander, May 25th, 2011

ProgrammableWebSimplicity 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?

Both comments and pings are currently closed.

47 Responses to “1 in 5 APIs Say “Bye XML””

May 25th, 2011
at 8:59 am
Comment by: James Chevalier

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.

May 25th, 2011
at 11:45 pm
Comment by: Andy Powell

..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 ?

May 26th, 2011
at 8:14 am
Comment by: Andy Davies

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.

May 26th, 2011
at 9:02 am
Comment by: Stewart Sims

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?

May 26th, 2011
at 10:11 am
Comment by: Casey Strouse

I love JSON because it’s way easier to design documents in and to parse. Also, libraries for working with JSON (in general) seem to be better designed and easier to use.

May 26th, 2011
at 10:32 am
Comment by: Merennulli

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.

May 26th, 2011
at 10:49 am
Comment by: Paul W. Homer

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.

May 26th, 2011
at 11:05 am
Comment by: 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.

May 26th, 2011
at 11:42 am
Comment by: Scott McCain

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.

May 26th, 2011
at 8:17 pm
Comment by: 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?

May 26th, 2011
at 11:12 pm
Comment by: Simon Stewart

Once JSON schemas become more commonplace, then I reckon XML APIs will start to drop in popularity.

XML is way too verbose, particularly when it’s meant for computer consumption.

May 27th, 2011
at 1:37 pm
Comment by: Clinton Gallagher virtualCable.TV

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.

June 2nd, 2011
at 9:02 am
Comment by: Life After JSON, Part 1 « Eric F. Savage

[...] a enterprise consultant. JSON is where it’s at. It’s new. It’s cool. Why even bother with stupid old XML. JSON is just plain better. [...]

June 5th, 2011
at 10:37 pm
Comment by: 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.

June 6th, 2011
at 4:10 pm
Comment by: Where's Walden? » I feel the need…the need for JSON parsing correctness and speed!

[...] servers and browsers and between independent, cooperating web pages. It’s increasingly the format of choice for website [...]

June 6th, 2011
at 5:07 pm
Comment by: Jeff Walden: I feel the need…the need for JSON parsing correctness and speed! | Firefox Latest News

[...] between servers and browsers and between independent, cooperating web pages. It’s increasingly the format of choice for website [...]

June 15th, 2011
at 7:15 am
Comment by: The Rise Of The API, The Future Of The Web | Regular Geek

[...] 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 [...]

June 15th, 2011
at 11:56 am
Comment by: Quova Adds JSON, Keeps XML, As It Expands Developer Portal

[...] The company also added JSON as a response format, as so many other APIs have lately. Unlike the APIs ditching XML, Quova is keeping the XML format and expanding developer options. Also, the company added a [...]

June 16th, 2011
at 2:36 pm
Comment by: Talk #134: nicht jugendfrei | RadioTux GNU/Linux

[...] Web APIs verabschieden sich von XML (pfleidi,Felix) [...]

June 20th, 2011
at 7:26 am
Comment by: Internet Pro News » Blog Archive » The Rise Of The API, The Future Of The Web

[...] 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 [...]

June 27th, 2011
at 6:32 am
Comment by: johnson

It will be interesting to see how the battle between JSON and XML will affect the delivery of the Smartphone services, I noticed twitter and Amazon have migrated their API’s from xml to json as well.
http://www.liquid-technologies.com/xml-editor.aspx

August 10th, 2011
at 12:31 pm
Comment by: An API With a Sense of Humor

[...] to the modern API, it only returns JSON and has an option for a callback function, so you can integrate directly into your JavaScript [...]

August 20th, 2011
at 11:57 am
Comment by: hadron

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.

August 20th, 2011
at 2:22 pm
Comment by: Maddoxa

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?

August 20th, 2011
at 2:28 pm
Comment by: Adam DuVander

The stats come from our own API directory, which now has over 3,500 APIs. I’ve updated the post with a link and to make it clear where the data is coming from.

August 20th, 2011
at 3:54 pm
Comment by: David Ellis

@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).

August 24th, 2011
at 2:16 pm
Comment by: Ferenc Mihaly

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.

August 24th, 2011
at 8:57 pm
Comment by: Gabs

XML is not at all overkill. It’s by far the easiest to implement, to this day I can’t find what on earth json is.

August 26th, 2011
at 5:17 pm
Comment by: Twitter API Ditches XML For Trends: New Features Are JSON-Only

[...] is embracing the trend where 1 in 5 new APIs do not support XML. The trend is playing out, appropriately enough, with Twitter’s endpoint for accessing global [...]

September 12th, 2011
at 9:37 am
Comment by: Weather Underground Goes JSON-Only With New, Freemium API

[...] their API.  XML was the format of choice in the original iteration.  This is yet another sign of JSON’s wide acceptance as a standard in the API [...]

September 15th, 2011
at 12:05 pm
Comment by: Google Plus API for Public Data Released

[...] with many new APIs we see, Google Plus returns only JSON, not XML. Also interesting, OAuth 2.0 is already supported. Currently it appears that authenticating the [...]

September 23rd, 2011
at 10:52 am
Comment by: Early Winners and Losers of the Platform Wars

[...] increasingly at the expense of SOAP. More than 55% of those same APIs support JSON output, with 20% opting not to offer XML at all. Platforms that support modern protocols, formats and outputs enable developers to build great [...]

October 5th, 2011
at 11:16 pm
Comment by: Jdad

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.

October 7th, 2011
at 9:22 am
Comment by: 258 JSONP APIs: Get Your JSON Response Anywhere

[...] is popular, at least when it comes to API data formats. Of the new APIs we added to our directory, one in five supports only JSON. But how many support JSONP, which allows developers to load data directly on the client side no [...]

October 31st, 2011
at 10:22 am
Comment by: Tool

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?

November 4th, 2011
at 9:22 am
Comment by: Bryan Copeland

@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.

November 16th, 2011
at 3:25 am
Comment by: 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.

December 28th, 2011
at 9:38 am
Comment by: sean

I have used them both, and I have arguements on both, it’s based on perspective not age, i’m 22.

February 8th, 2012
at 6:51 am
Comment by: 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.

February 21st, 2012
at 7:07 am
Comment by: XML vs. JSON — How Many Data Structrues Does It Take… - XMLProNews

[...] 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 [...]

February 21st, 2012
at 9:09 am
Comment by: XML vs. JSON — How Many Data Structures Does It Take… - XMLProNews

[...] 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 [...]

March 9th, 2012
at 7:11 am
Comment by: Blogs From The Geeks » Blog Archive » Sundown in Solr Town – The Indexing Shootout - Intermittent insightful nuggets

[...] is the current format we send data to Solr to be indexed in, but as Web APIs did previously –- we’re going to challenge its verboseness as we ruthlessly hunt down [...]

April 3rd, 2012
at 12:00 pm
Comment by: sammy

mailbait.info makes heavy use of json. it was a perfect fit for light server side hosting requirements. cehck it out.

August 26th, 2012
at 9:54 pm
Comment by: Towards an XML-free future for the digital humanities | THATCamp Brisbane

[...] rapidly moving towards a predominantly mobile desktop metaphor based on JSON, HTML5 and Javascript, there seems no room for old-style ‘enterprisey’ XML in a future that is rushing towards [...]

September 13th, 2012
at 10:44 am
Comment by: Google Weather API

[...] to it, because of its simple interface and streamlined results. Even the developer preference for JSON over XML hasn’t tempered interest in a Google weather [...]

September 14th, 2012
at 1:41 pm
Comment by: Develop in the Cloud - Karl Hakkarainen - XML Could Have Been a Contender

[...] in the decade, JSON came on quickly. In 2011, Programmable­Web reported that one new API in five supported [...]

December 17th, 2012
at 9:53 am
Comment by: Leading APIs Say “Bye XML” in New Versions

[...] JSON has been apparent for some time. Previously we’ve pointed out that 1 in 5 new APIs were choosing JSON over XML. The trend has continued, with an even greater percentage of APIs saying goodbye to XML. [...]

Follow the PW team on Twitter

ProgrammableWeb
APIs, mashups and code. Because the world's your programmable oyster.

John Musser
Founder, ProgrammableWeb

Adam DuVander
Executive Editor, ProgrammableWeb. Author, Map Scripting 101. Lover, APIs.