Coffee Chat #2: XML vs. JSON
When deciding to choose between XML and JSON it’s important to be able to understand the strengths and weakness of each – XML is older and more refined but JSON is lighter weight and more optimized for newer technologies. You need to understand your business case, how you will be using the data, and how the platforms you’re interacting with are exchanging data.
XML (Extensible Markup Language) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable (1). We discussed how the technology has been around longer, making the data easier to look at and allows you a greater possibility of knowing what problems will arise. XML may be more restrictive but HR Open provides a mechanism for extensions.
Factors that help decide whether to use XML or JSON really depend on what you’re trying to accomplish. Data dumps are easier to read through XML, as the large file can act as a portable database. JSON is easier to transform objects using code and express the interconnections between the data. Sometimes your file format will be dictated by the companies you’re exchanging data with, in fact several people commented how they take data in through JSON and generate an XML output.
It’s also important to talk about APIs. Swagger (3), JSON based, is a way to develop APIs and provides documents for accessibility. We’ve seen that a lot of the tools for developing APIs seem to be more plentiful than ones for XML which could present a move from XML SOAP to more RESTful web services (although XML can be restful too). The AWS API Gateway uses JSON to manage API configuration, development, and usage demonstrating that JSON is more mature.
HR Open considers the business cases when developing the standards, defining the JSON first , then generating the XML. This allows the implementer to determine which format to use when incorporating the standards in their products.