Over the past decade or so, REST + JSON has emerged as the dominant approach to building APIs. This might seem inevitable now, but it’s worth reflecting on how and why this combination became the default choice for so many developers and organizations. Here’s a breakdown of why REST won as an architectural style and why JSON became its sidekick in API development.
When Roy Fielding’s dissertation Architectural Styles and the Design of Network-based Software Architectures introduced the REST architectural style in 2000, it didn’t immediately take the world by storm. Established protocols like SOAP, CORBA, and DCOM were already widely adopted and entrenched in the industry. REST’s path to prominence was anything but easy—it faced an uphill battle against these more established approaches. However, REST ultimately broke through and became dominant, primarily due to the following reasons.
At its core, REST (Representational State Transfer) is simple. If you can make an HTTP request, you can interact with a RESTful API. There’s no need for complex frameworks or understanding esoteric protocols. You’re using the same HTTP methods (GET, POST, PUT, DELETE) that power the web itself. In contrast, SOAP, an earlier popular protocol for APIs, introduced a whole new world of XML envelopes, WSDL files, and extensive standards for security and transactions. While SOAP is incredibly powerful, especially for enterprise applications, it also has a much steeper learning curve. REST’s simplicity is one of the key reasons it took off.
REST was designed to work with HTTP, and it shows. The methods (verbs) in HTTP like GET, POST, and DELETE align perfectly with CRUD operations in APIs. Resources in REST are nouns, like “/users” or “/orders,” that you can act upon with these verbs. This close match between the web’s underlying protocol and REST’s design makes it incredibly natural to work with and allows REST to take advantage of HTTP's existing approaches to authentication, authorization, security, and so on. REST doesn't try to hide HTTP; it embraces it. This is in stark contrast to earlier systems that tried to abstract away the underlying transport mechanisms, leading to leaky abstractions and confusing errors.
The web is everywhere, and so is HTTP. Every device, from your smartphone to your fridge, can speak HTTP. By building an API on HTTP, you’re making it accessible from practically anywhere. There’s no need for specialized clients or libraries to interact with a RESTful API; any HTTP client will do the job. This ubiquity means your API is open to the widest possible audience, whether it’s other applications, devices, or even other developers.
At the time REST was introduced, “JSON” didn’t even exist. It wasn’t until 2001 that Douglas Crockford sent the first JSON message, and JSON wouldn’t be standardized until 2006. Yet, much like REST, JSON would eventually surpass the entrenched players in the data transfer space—namely XML and proprietary binary formats—to become the default choice. When paired with REST, JSON became the secret weapon that propelled them both not just to prominence, but to dominance.
JSON (JavaScript Object Notation) is simple to read, write, and validate. It’s a lightweight data-interchange format that’s easy for humans to read and write, and easy for machines to parse and generate. XML, which was the dominant data format in the SOAP world, is more verbose and comes with a lot of overhead, like namespaces, schemas, and various encoding rules. JSON, by contrast, is just a collection of key-value pairs, arrays, and basic types. It’s straightforward, which makes it ideal for most modern APIs.
One of the biggest reasons JSON took off is because of its native support in all modern browsers. JSON is based on a subset of JavaScript, which means it can be parsed easily by any JavaScript engine—no additional libraries needed. This made JSON the natural choice for web APIs, especially with the rise of single-page applications (SPAs) that rely heavily on AJAX calls to communicate with back-end services. The ability to work seamlessly with JSON directly in the browser was a game changer for front-end developers.
It’s not just browsers that love JSON; it’s everywhere. JSON parsers are available in practically every programming language. Whether you’re working with Python, Java, Ruby, or something more niche, there’s a JSON parser for you. And if, for some reason, your language of choice doesn’t have one, writing a JSON parser from scratch is simple, especially compared to XML parsers. This widespread support makes JSON a safe and easy choice when building APIs that need to be consumed by a diverse set of clients.
Let’s face it, developers spend a lot of time looking at API responses, especially when debugging or developing new features. JSON’s human-readable format makes this a much less painful experience. While more efficient serialization formats like Protocol Buffers or MessagePack are available, they trade off human readability for performance. For most applications, especially those where development speed and ease of debugging are crucial, JSON strikes the right balance.
The combination of REST and JSON won out because of their simplicity, alignment with the web’s underlying technologies, and widespread support across platforms and languages. They’re not perfect for every situation, but for most modern APIs, they offer a pragmatic approach that balances ease of use, performance, and broad compatibility. As a result, REST + JSON has become the default choice for building APIs in the 2020s, and it’s hard to see that changing anytime soon.
