I don’t expect that many developers today fully appreciate the quiet glory that is REST and JSON.

But then, most developers today have not been around the software business as long as I have. It’s only natural that we old timers have a clearer idea of how incredibly far the technology has come.

I’ve been writing code long enough to remember when computers had 5¼-inch floppy drives and exactly zero network cards. Connectivity was a 2400 baud modem talking to a local BBS via the plain old telephone system. The notion of two computers talking to each other was conceivable—but just the two. The Internet was just a twinkle in the eyes of a few DARPA engineers.

Back then, getting two computers to exchange text and basic file data was pretty well established. But getting one of those computers to execute some code and pass the result back? Well, that was really, really challenging. Today, we do it with the REST/JSON combination. It’s amazing, really.

Early efforts at developing remote computing were crude by today’s standards. Windows was the dominant operating system. To allow Windows software to communicate over a network, Microsoft developed DCOM, the Distributed Component Object Model. DCOM handled data transformation, security, and network transport under the hood, allowing computers to execute remote code and pass the results back and forth. But it was notoriously complex (see marshalling). And of course, it only worked on a local Windows network.

Early attempts at making remote computing work across language and network boundaries revolved around CORBA, the Common Object Request Broker Architecture. CORBA provided a means for code written in different languages and running on different machines to act as if they were local objects. You had to use an Object Request Broker (ORB) and the Interface Definition Language (IDL) to get everything to work. And yes, like DCOM, CORBA was complex, brittle, and challenging to keep up and running. On top of all that, CORBA was expensive and implemented by the big tech companies.

In short, both DCOM and CORBA tried to make remote calls feel local. And both collapsed under their own weight.

SOAP and WSDL

The first attempt at abstracting away much of the complexity of getting one computer to execute code for another was SOAP, the Simple Object Access Protocol. SOAP advanced the cause by leveraging HTTP as the network protocol and XML as the communication medium. SOAP used an XML-based description language called WSDL (Web Services Description Language) to define the structure and behavior of web services.

SOAP was a step in the right direction, but it too required pretty much everything to be specified ahead of time. Data and objects had to be structured and defined before any communication could happen. It looked promising at first—XML over HTTP!—but developers found themselves buried under layers of WSDL, namespaces, and rigid schemas. Each small change in an API meant regenerating client stubs, and debugging was onerous. A missing XML namespace could consume an entire afternoon.

SOAP was, however, a solid step forward. And the lessons learned from SOAP helped pave the way to REST and JSON finally becoming the standard communication protocol.

There were other protocols along the way, such as Java’s RMI (Remote Method Invocation) and XML-RPC, which met specific needs, but the progression from DCOM to CORBA to SOAP/XML to REST/JSON is the main highway that led us to where we are now.

Revel in the glory

I imagine that many developers today don’t properly appreciate the glory that is REST/JSON because it is such an elegant and beautiful solution. In 2000, it was Roy Fielding who had a “light bulb over the head” moment and saw the connection between standard CRUD operations and the GET, POST, PUT, and DELETE verbs of the HTTP protocol. His lovely insight opened our eyes to the notion that the web was more than a platform for serving documents. The web was, in and of itself, a giant computing platform.

Just like that, all of the marshalling and crazy protocols like DCOM, CORBA, and even SOAP were abstracted away. Today, REST rides along on a system that nearly every single computer in the world already can do. Security? Well, good old SSL/TLS will do the trick. And by leveraging Douglas Crockford’s very flexible and powerful JSON, or JavaScript Object Notation, nearly every difficulty and complexity in moving objects and code between computers and operating systems vanishes in a puff of smoke. REST made remote procedure calls as universal, scalable, and programming language-agnostic as the web itself. JSON took care of the rest.

Today, using REST/JSON is about as familiar to developers as breathing. Practically every library, programming language, and DBMS in the world supports REST/JSON and consumes it natively and naturally. REST/JSON could easily be viewed as the lifeblood of the web today.

So next time you curl an endpoint and watch a neat little JSON blob pop out, remember—this used to take days of configuration, COM registration, and XML misery. REST/JSON didn’t just simplify distributed computing, it democratized it. Take a moment and revel in the glory that is the REST protocol and the JSON universal data format. And appreciate the struggle it took to arrive at such an elegant and simple solution.