Just Use Json
History of Serialization Formats
Serialization formats have a pretty long history dating back to the 1980s when Sun Microsystems introduced XDR (External Data Representation) as part of their Network File System (NFS) protocol. XDR was designed to provide a standard way of encoding data for network transmission, allowing different computer architectures to exchange information seamlessly. This paved the way for more sophisticated serialization formats, including ASN.1 (Abstract Syntax Notation One) which gained popularity in telecommunications and cryptography, and CORBA’s CDR (Common Data Representation) used in distributed object systems. There may have been standardaized formats before XDR but I have neither studied nor known them. But XDR is still alive and can be used today with libc RPC interfaces.
As the internet evolved, new serialization formats emerged to meet changing needs. XML (eXtensible Markup Language) became widely adopted in the late 1990s and early 2000s for its human-readable format and flexibility. However, its verbosity led to the development of more compact alternatives. JSON (JavaScript Object Notation) gained traction in the mid-2000s for its simplicity and native support in web browsers. YAML (YAML Ain’t Markup Language) also emerged as a human-friendly, easy-to-read format, particularly popular for configuration files. Subsequently, binary formats like Protocol Buffers, MessagePack, and Apache Thrift were developed to offer improved performance and smaller payload sizes, catering to the growing demands of high-speed, large-scale data exchange in modern distributed systems.
From XML for Everything to XML is bad for Everyone
In the early 2000s you could not escape XML even if you wanted to. It was state of the art and it was everywhere. We were going to use it for communication. And with DTDs or Xml Schema Documents we were going to use it to validate communications. We were going to use it to sepcifiy the styling and formatting using XSLT. We were going to use XPath to specify subsets of XML documents as part of the XSLT standard and we were going to use XQuery to query XML files allowing us to build a document database around XML documents. Java beans were using it to specify everything. And we were creating communication protocols based on XML as a standard.
As you would inevitably expect it to, this attitude of let’s use XML for everything led to an industry backslash. This coincided with the rise of a new cohort of web based startups that were starting to grow in popularity and had to face scaling issues due to growth that was unheard of before that. Around this time REST starts making an appearance in the industry and is gaining ground in engineer mindspace. Compared to SOAP, the new technology is very easy to grok and much easier to setup. It uses HTTP verbs for the CRUD operations and can be used even with simple tools like curl. There is no need to use complex tooling that could generate and digest XML as before with SOAP. And along with this drop in usage of SOAP, comes the decline in usage of XML.
In to this mix comes JSON, first invented by Douglas Crockford around 2000/2001, this was a subset of Javascript when it was first created. It was simpler to understand and write than comparable XML and most certainly less verbose. This meant that it was the perfect accompaniment for REST to use as a serialization format although nothing dicatated that it must be JSON. So most of the web companies (SaaS, Social Media, etc) started using the REST + JSON as the default communications framework. And to throw another complication in to the midst of all this, the microservice revolution took off around the same time as well. From monoliths to Service Oriented Architecture to microservices, this meant that it was time to churn out more and more microservices that had drastically simpler interfaces. Due to the published best practice from around the time being that a given microservice would do one thing and one thing only, we started creating simpler services by the dozen. And this meant we needed to make the interfaces as simple as possible.
And that in a nutshell is how we went from SOAP + XML to REST + JSON in a few years. I watched in fascination and the titans in the industry debated and quarraled over all this since I was just a junior engineer with no real idea about the tradeoffs involved. All this was jargon wars for me. And now a decade on, I relaize that some profound changes happened during that era.