API Formats: Why JSON won over XML

Why did JSON replace XML as the preferred representation format for APIs? There are many reasons one can speculate about, and there probably is no way to isolate one single reason, or to even find the main reason.

But it is possible to have opinions about this, and in this video I explain one of the factors that in my experience contributed greatly to JSON being preferred over XML. Other factors of course played a role as well, such as XML's verbosity and the rather complex ecosystem of related specifications.

But one main factor was that XML at its heart is a document format. It is great for representing documents, and it can represent data, but that's not its strong suit. Being a document-focused format, it represents everything as trees, which then have to be traversed in order to process information from those documents. That results in extra work and a cognitive dissonance between the data that is being represented in APIs (in XML's document-centric format) and the way how most applications internally represent data (oftentimes in structured object models).

JSON came along and changed that by simply reusing the object model of an existing language (JavaScript, as JSON simply stands for JavaScript Object Notation). That was a much better fit for most APIs (which often are using structured data and not documents) and developers (who often work in languages that have object models close to JSON). This meant no more parsing and traversing of XML trees, instead the JSON objects could be relatively directly mapped into native data structures.

You're more than welcome to disagree (please comment if you do!), and this is of course an opinionated and slightly exaggerated view. But it is one of the factors that are often overlooked, so giving it a bit more visibility seemed appropriate.

[jholloway]

I cannot overstate how much I appreciate a video on the WHY of computer programming formats and concepts and not just another generic HOW video.

[ArneSolli]

Great video and to the point! When I started using XML for "real world" data back in the 1990s I really found my self in a straight jacket. A "huge" problem was double hiearchies, which often occurs in the real world and seldom in documents. Then it occured to me that XML was really the same data model as the IBM IMS from the mid 1960s. In my early dbms design and development I used the Codasyl network model which included that a node could be part of two different hiearchies, i.e. had a parent and a step-parent, direct link from grandchild to grandparent and so on. So I though of XML as pre Codasyl (Network model), i.e. modeling pre 1970s. When JSON came about it was also a flash back, since it in a way like re-inventing th Relational Datamodel (Codd 1974). And I finally could use objects, lists and arrays like in a relational DBMS and with less "rules"

[rogerhuang]

I like the way you structured the content in the video. Simple and interesting!

[ArkAnudDinYaSin]

This is where all technical discussions should begin, the “Why?”.

What problem compelled the choices or the reality we live in…I don’t understand why in the modern world we care so little about the “Why?”. I believe it is why we end up feeling trapped learning and using the wrong tools, the problem the tools were built to solve has long been solved and now we have new problems but the tool we are using became dogma.

[ElCidPhysics]

Thanks for this video. I’m currently working on a project that needs some data, basically lists of protocols for radiation therapy plans. I wanted to avoid adding a database initially, so I created the protocols in a plain text document using xml. But over the last week I’ve been thinking json would probably have been better. Your video pushed my 100% there. Will be converting xml to json. May even bite the bullet and create the database.

[AnVinhNguyen]

Really appreciate the history of the 2 formats. Great content. Thank you

[LiamQuin]

For sure DOM hurt XML, and for sure JSON is a better fit when the programmer is in total control of the format. It's not 100% true that we didn't think about such infrastructure use cases when developing XML, but you're right that documents were primary.

[Enigma]

What I dislike about both of them is that both are in effect trees. I want the power of a graph.

[culibarri]

As someone who wants to transition from UX to technical writing, which would be most appropriate to learn? For API documentation

[BenRangel]

Seems to me a huge weakness of XML is that you need a schema to parse the basics like: is this node an array? Is this value a string, bool or number?
In JSON at least you know that much.

[Leb]

Why is Antonio Banderas giving a lecture on JSON 😳

[orlovskyconsulting]

I too catched up with XML, SOAP is still a thing, what most disliked that XSD /XSLT, Xpath, it just to verbose. In SOAP you need to maintain the WSDL on client and server side, and of course it did many times wrong.

[WantMore-mcdx]

API for whom? For many backend developers we live by XML and it's technologies. It's other things for frontend developers

[michelbormans]

What about complex json structures? Are you not thinking of mini api's versus bigger api's? The complexity is moving away/out of the one data structure but reappearing in the orchestration of the many api's... no?

[jaimenavoncohen]

Great post ! I completely agree and buy your hypothesis. There is one thong though that doesn't fit and this is that most Document oriented databases (like MongoDB or CouchDB) use JSOn and not XML to store structured documents. Could it be that these engines are used within JabaScript code ?

[kedimnvfjnnvfjffurju]

Before XML you had standards like the horrible EDIFACT for machine to machine communications, compared to them XML is a bless and JSON is even better.