While doing some background research on distributed software, I rediscovered some of the history of two major themes that affect many developers today: the Object-Oriented programming style (OOP) and Representational State Transfer architectural style (REST). Even though the two concepts seem to focus on very different aspects of designing and implementing systems (local coding vs. distributed coordination), I was pleasantly surprised to find that the two people responsible for these important paradigms — Alan Kay for OOP and Roy Fielding for REST — both say that long-term viability is a key goal of their work. They even use some of the same language to describe and clarify implementation details of their ideas.

Alan Kay's OOP came out of his work at the Xerox PARC facility in the 1970s. One of Kay's goals was to make it easier to create large-scale systems that could adapt over time without the need to be shut down and restarted. He called these "growable systems." Fielding's REST model was developed a generation later in the 1990s at University of California Irvine. Fielding said that designing systems that are evolvable, can be modified at runtime, and can "last for decades" is one if the primary motivators for his architectural constraint model.

One of the key concepts that link the two men together is the emphasis on a message-oriented approach to communicating between components. What I find very interesting is that many developers today use what they think are OOP and REST principles to create applications for the Web but few actually leverage the message-oriented model both Kay and Fielding say is so important.

I thought it would be interesting to explore the history of the two ideas and note the similarities. I also think it is important for software developers and architects to acknowledge the common message-passing features of OOP and REST and consider ways to make it easier to employ these ideas in product applications today.

Alan Kay on Message-Passing

When Alan Kay first coined the phrase "object-oriented" he was trying to convey the idea that coding applications should be a process of a) identifying the objects that best express a problem domain and then; b) representing both the object and its processing in a concise and consistent manner. He envisioned passing simple messages between objects and allowing the objects to use code 'hidden' within the object to operate on those messages. Unfortunately, that's not quite how Object-Oriented Programming (OOP) progressed.

In an 1998 email, Kay made public his regrets in using the words "object-oriented" to name this concept. He complained that too many had focused on the object and missed the importance of the "message" in his design. And he openly worried that this would lead to systems that wouldn't scale and would result in far too much coupling between components.

"I'm sorry that I long ago coined the term 'objects' for this topic because it gets many people to focus on the lesser idea. The big idea is 'messaging' - that is what the kernel of Smalltalk/Squeak is all about." — Alan Kay, 1998

Kay continues to chide the software community on missing this fundamental point. He often complains that too many OOP systems fail to implement his message-orientation and opt instead to expose internal properties directly. He captured the basic problem in a phrase he often repeated:

"Lots of so called object oriented languages have 'setters' and when you have a setter on an object you turn it back into a data structure." — Alan Kay, 2011

The Message Model of the WWW

The basic concepts of the World Wide Web (WWW) are also rooted in the notion of passing messages. Initially, the entire web was a set of linked documents. In the 1989 paper that outlined the WWW, "Information Management: A Proposal," each document was described in a single response message.

Requests were, at first, simple messages with an instruction and an address:

GET /telephone-list.html

This message was then interpreted by the receiver which retrieved the requested data and returned it in the form of another message:

200 OK content-type: text/html content-length: XX <html> .... </html>

As the Web grew more sophisticated, both the request and response messages expanded to include a simple name/value pair to carry metadata and additional formats for expressing request variables and/or parameters to pass when sending data to the server. By the time the HTTP protocol that underpins the entire Web was standardized in 1996, all the components of the WWW that we know today were in place.

*** REQUEST *** GET / HTTP/1.1 Host: api.example.com Accept: */* Authorization: Basic XXX Accept-Encoding: gzip, deflate *** RESPONSE *** HTTP/1.1 200 OK Vary: Authorization,Accept Transfer-Encoding: chunked Etag: "1q2w3e4r5t6y" Content-Type: application/vnd.collection+json; charset=utf-8 Date: Wed, 01 Dec 2014 14:59:30 GMT Allow: GET,OPTIONS,HEAD Cache-Control: public,max-age=30 ...

Fielding on HTTP and REST

Back in the mid-90s Roy T. Fielding started working in his spare time on the library that would eventually be the catalyst for understanding the principles at the core of the World Wide Web. His coding project was the first version of libwww-perl or "LWP." At the time, it was only the second WWW library available (the first was libwww written in "Objective-C" by Tim Berners-Lee).

Fielding's library was initially called the "HTTP Object Model." But that name didn't last for long since, as Fielding tells it.

"REST was originally referred to as the 'HTTP object model,' but that name would often lead to misinterpretation of it as the implementation model of an HTTP server. The name 'Representational State Transfer' is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use." — Roy Fielding, 2013

In language that is similar to Kay's, Fielding describes a "well-designed Web application" as one that relies on a virtual state machine updated by executing state transitions. Fielding used the "message-passing" paradigm to help codify the essentials of in his REST style description.

Distributing Objects Misses the Mark

While the roots of the WWW are steeped in the idea of enabling state transitions via message-passing, that's not how most developers approach the task of "programming the Web." Instead, many service implementations for the Web today implement a kind of "distributed object" style interface. Objects are given URLs as identifiers (e.g. http://example.com/users/mike ) and the responses from these URLs look like simple objects:

** REQUEST ** GET http://example.com/users/mike ... ** RESPONSE ** 200 OK HTTP/1.1 Content-Type: application/json Content-Length: XX { "user" : { "fullname" : "Mike Amundsen", "email" : "mike@example.com", "phone" : "123-456-7890", "address" : { "street" : "123 Main St", "city" : "Byteville", "state" : "MD", "zip" : "12345" } } }

In fact, these are not actually objects; they're data structures and these responses start to look very much like the data structures Alan Kay complains about.

Passing Messages Scales the Web

This "Object Model First" style is not the idea that Tim Berners-Lee and Robert Cailliau had in mind when they described the WWW in their 1989 proposal to CERN:

"HyperText is a way to link and access information of various kinds as a web of nodes in which the user can browse at will. Potentially, HyperText provides a single user-interface to many large classes of stored information such as reports, notes, data-bases, computer documentation and on-line systems help." — Tim Berners-Lee & Robert Cailliau 1989

The WWW as originally proposed was a "Message-First" approach that made it possible for clients and servers to interact without first writing custom code. And that is the pattern Fielding used in his LWP library. In the WWW-style, the responses contain more than just data, they also contain hints and instructions on how the client application can manipulate the data using additional messages passed to the server. For example, a WWW-style response to a request for a user identified by the URL http://example.com/users/mike might look like this:

** REQUEST ** GET http://example.com/users/mike ... ** RESPONSE ** 200 OK HTTP/1.1 Content-Type: application/vnd.collection+json Content-Length: XX { "collection" : { "href" : "http://example.com/users/", "items" : [ { "href: "http://example.com/users/mike", "data" : [ {"name" : "fullname", "value" : "Mike Amundsen"}, {"name" : "email", "value" : "mike@example.com"}, {"name" : "phone", "value" : "123-456-7890"}, {"name" : "street", "value" : "123 Main St."}, {"name" : "city", "value" : "Byteville"}, {"name" : "state", "value" : "MD"}, {"name" : "zip", "value" : "12345"} ], "links" : [ {"rel" : "edit", "href" : "http://example.com/users/mike;edit"}, {"rel" : "friends", "href" : "http://example.com/users/friends"} ] } ], "template" : { "data" : [ {"name" : "username", "value" : ""}, {"name" : "email", "value" : ""}, {"name" : "phone", "value" : ""} ] } } }

In this second example, you can easily find the instructions for crafting new messages (the " template " object) and hints on other available data (the " links " collection). You can also see that, like the format most commonly used on the Web today (HTML), this response provides no details on the object model hidden behind the server interface. This is what the message-passing approach looks like on the Web. Clients and servers do not need to agree on the object model, they just need to agree on the message format (called a media-type in the standards world) and the various field and actions words used in the domain.

OK, I Get the Message!

So, it turns out that both Alan Kay and Roy Fielding were thinking along the same lines. Kay wanted to promote the creation of "growable systems" — ones that could safely change over time without having to be stopped, rewritten, and redeployed. To accomplish this, he designed a coding approach that hid functionality in components and exposed messages to the outside world.

And Roy Fielding was describing essentially the same thing when working to create software that "lasts decades." But instead of focusing on components, Fielding created a software style that focused on the connectors — the way information was shared between the components. And this style (called REST) also relied on message-passing.

So why do many developers today continue to ignore this message-passing model and instead use "getters" and "setters" in their code and pass data structures over the web? There are a handful of likely reasons. First, it is rare that developers learn about the history of Fielding and Kay and what they originally intended. Second, many developer tools are designed to promote getter/setter patterns in code and distributed objects across the network. Finally, most testing tools focus on explicit objects and properties since they are easier to validate than details within a message.

With all these hurdles, it can be tough for a developer team to maintain focus on what Kay and Fielding said so long ago. We can, however, make it better for all developers when we provide in-depth training, look for tooling that supports these proven paradigms, and provide QA environments that make it easier to test and debug distributed software that scales — all through more reliance on message-passing patterns.

And that can get us all closer to building "growable systems" that can "last for decades."

About the Author

Mike Amundsen (@mamund) is Director of Architecture for the API Academy from CA Technologies. He is responsible for working with companies to provide insight on how best to capitalize on the myriad opportunities APIs present to both consumers and the enterprise.

Amundsen has authored numerous books and papers on programming over the last 15 years. His most recent book is a collaboration with Leonard Richardson titled "RESTful Web APIs" published in 2013. His 2011 book, “Building Hypermedia APIs with HTML5 and Node”, is an oft-cited reference on building adaptable Web applications.

More articles in this series: