,

API Series: All JSON, All The Time

Znode Multifront

In the previous post about our API we talked about why we decided on REST, and this post is about another decision point in API design: what format should you use for the data? In today’s world this means supporting XML or JSON or both, which is something that can spark a bit of a holy war with some people, and admittedly we had much internal discussion about this as well. But in the end we decided to support JSON only in our API.

XML Web Services

Historically, APIs and web services have centered around XML, and rightfully so. It’s a well-known standard and understood format, and is a huge reason why APIs and web services have become so prevalent over the last 15 years. Enterprise tools and software packages were created to generate and consume large amounts of XML being passed around the web, opening doors into external services that weren’t there before.

And while XML has played such an important role in the web service landscape, it’s not without its faults. It’s heavy and tends to be tool-centric, so much so that different tools have different ways to generate and parse XML data, sometimes causing inconsistencies that make it difficult to work with.

JSON and REST

But these last few years have seen web developers get back to their HTTP roots. They started asking themselves, “Why do I need a tool to handle all this XML when I can simplify the data and leverage HTTP to process it?”. This lead developers to embrace JSON and REST, a data format and an approach that gets developers back to the heart of web itself. Plus, there isn’t a single tool or software package out there that understands XML but not JSON. JSON is as ubiquitous now as XML has always been, which has helped increase its adoption.

No Angle Brackets

For us, early in the development cycle for the API, we experienced our own issues when trying to support both XML and JSON. Exposing and consuming JSON data from our API turned out to be easier, more flexible, and a better overall experience than XML. And if supporting XML was frustrating for us, the creators of the API, then what would be it like for our customers and partners?

Ultimately, JSON accomplishes the same things as XML, is much lighter in terms of data payloads, and simply gives consumers of an API a better development experience. This is why you won’t find a single angle bracket in our API. It’s all JSON, all the time.