When working with our customers and their integrations, we sometimes find ourselves discussing whether it would be better for an integration to use XML or JSON. This is not to say that there aren't other transport languages. But XML and JSON are probably the most common.

For integrations with existing APIs, you usually won't have a choice (since the API defines the transport language). However, when you look at building all new integrations for a SaaS app, and you'll need to set up a new API as part of the development, you can also determine which transport language is best suited for your scenario.

We'll look at why XML and JSON are so popular and see what advantages one might have over the other, but first, let's examine transport languages.

Understanding transport languages

When a message is sent from one system to another (such as what happens with integrations), the message has a transfer protocol and a transport language. Transport languages are also known as data exchange formats or data interchange formats.

Common transfer protocols include HTTP, FTP, and TCP. Common transport languages include CSV, JSON, XML, and YAML. In theory, we could use almost any transfer protocol with almost any transport language. However, specific transfer protocols are usually coupled with certain transport languages.

Transport languages vs programming languages

Transport languages are not to be confused with programming languages. Transport languages describe data for purposes of transport or data exchange. Devs use programming languages to build programs (apps and services) that execute to make things happen. We might think of transport languages as describing something static, but programming languages as causing change. And now we come to XML and JSON – the most common transport languages used with HTTP for sending messages over the web.

XML in brief

XML (eXtensible Markup Language) is derived from SGML (Standard Generalized Markup Language), the specification for defining markup languages. Markup languages are used to mark up text content electronically (much like an editor or proofreader did by hand in the old days) to define content structure, formatting, and internal relationships.

SGML was developed originally to make it straightforward to encode paper documents in electronic form. As a result, SGML is comprehensive and complex. XML was designed to describe structured data, such as would be stored in database tables and rows, rather than technical articles and books (the types of documents that SGML was initially intended for).

XML is now the basis for many different types of documents. Documents with a .xml file extension are usually encoded in XML, and many other file types use XML without making it obvious. For example, Microsoft's .docx and .xlsx filetypes both rely on XML behind the scenes. And many web apps still use XML as their transport language.

Here's an XML example of fuel inventory data:

We can see that, in addition to being an easy way to describe structured data, XML is generally human-readable. This readability is one of the reasons XML became popular as a transport language and was, for many years, the de facto standard for transmitting structured data via the web.

JSON in brief

JSON (JavaScript Object Notation) is a subset of the JavaScript programming language – the most popular scripting language for websites and web apps. But JSON was built to be a lightweight format for storing and transferring structured data and is not a programming language.

Unlike XML, which is used in many contexts outside the web, JSON is mainly used for its intended purpose: to transmit data between apps. Since a good portion of today's web uses JavaScript, and JSON is the native data format for JavaScript, it makes sense that more and more of the HTTP messages flying across the web are in JSON. JavaScript can be used with other transport languages (such as XML) but doing so requires more work than when using JSON.

Here's the same fuel inventory data, but shown in JSON this time:

This JSON example appears just as readable as the earlier XML example. The primary difference is that the JSON example is slightly leaner than the XML example.

Should your integration use XML or JSON?

XML or JSON could work for just about any scenario. That said, here are a few reasons SaaS dev teams frequently use JSON for data exchange.

• Ease of programming. We touched on this, but since JSON is a subset of JavaScript, and JavaScript is the dominant web scripting language, it's often easiest for devs to go with JSON. As noted, JavaScript apps can use other transport languages, such as XML, but more work is required to make that happen. Devs will take the less complicated path if there's no good business reason to use XML.
• Lack of verbosity. In XML, when we open a tag such as <type>, we then need to close it with </type>. In JSON, when we use "type":, we close it with a ,. That makes a JSON message smaller than its XML doppelgänger. This difference doesn't appear very great in a small message, such as our examples, but when we consider many millions of messages, the space and time savings from using JSON begin to add up.
• Intended purpose. While XML came to be used as a transport language, it wasn't built to be one and is sometimes poorly suited for that role. On the other hand, JSON was created for data exchange, giving it a built-in advantage.
• Simplicity. XML can be confusing to work with because of the substantial number of XML variations and versions that exist. JSON has less than a handful of versions.

While it seems JSON has the advantage, XML is not without its adherents. Here are two benefits of using XML with integrations:

• Strictness. Some devs prefer XML to JSON because of the strict schema built into XML. A server can say, "I expect XML in this format," and if your submitted data doesn't conform to that DTD (document type definition), nothing is processed. On the other hand, JSON sometimes requires a bit of guesswork to determine if the server expects a number or string in a specific scenario.
• Transformation. Devs can also easily leverage built-in XSLT (extensible stylesheet language transformations) to map XML data from one schema to another. This can significantly speed up the process of data transformation.

How about existing apps?

If you are building a new app and API, you can choose the best transport language for your scenario. But what if you have an existing API and transport language but need that data in a different format?

For example, your B2B SaaS app has an API that exports data in XML, but some of the business apps your customers are using (the ones you need to build integrations with) have APIs that only accept JSON imports.

In situations like this, we need to change the data from one transport format to another. Many different programming languages have libraries available to help with this task.

However, this is where an embedded iPaaS like Prismatic's can help. We provide the Change Data Format Component to all of our customers. This pre-built code allows you to take an input in a standard data format (such as XML or JSON) and programmatically convert it to another standard data format (such as JSON or XML).

For more content on data exchange formats and other integration topics, check out our guide to API integrations.