Consider the UNIX shell pipeline. It allows independently-developed tools conforming to its semantics to be chained together serendipitously to create new tools. This reuse is based entirely on the uniform stdin/stdout bytestream interface. Different data formats can pass through the pipeline, depending on the tools involved and the command-line options given to them. The tools, of course, have to understand the data formats they exchange. But best of all, the same power applies to more than just the shell; any UNIX app can open its own pipes and chain together whatever tools it wants to.

Does this mean all UNIX tools are reusable? Of course not. But without the simple framework that the pipe capability provides, the tools couldn’t be combined in that fashion to create new tools. More importantly, the presence of the pipelining framework drives the form of the tools. Nobody would even think to develop tools that performed small tasks that could be combined into larger ones if the pipes weren’t there to begin with.

Now, what if each tool instead specified its own specialized interface for sending data into it or getting data out of it? No more ad hoc tool chains. You’d have to develop special applications just to interact with each tool’s interface, and there’s less likelihood of that because the benefits are limited.

REST as realized in HTTP has some similarities to this. The uniform interface is useful for many distributed applications (and as we both agree, is specifically tuned to deal with issues related to networking and distribution), and MIME types standardize the formats of (some of) the data such applications produce and accept. The existence of this framework drives developers to reuse it; they build their applications to fit the framework in order to gain its benefits, and the more applications that use it and conform to how it’s intended to be used, the more likely they are to be usable together and reusable. But without such a framework in place, applications are forced to define their own interfaces and their own data formats, thus forcing anyone who wants to communicate with those applications to build specialized code to do so. Again, this is less likely because the benefits are fewer.

At QCon San Francisco in November 2007, I watched Pete Lacey build a RESTful expense reporting system during his talk. He had only a few minutes to do this, but first he had it producing HTML and manipulated with his browser, and then he added the ability to handle the CSV format, after which he could use his application via Excel. This in turn meant that any tools based on Excel suddenly became capable of using his expense reporting system. Adding support for other data formats would have expanded its capabilities and reusability even further. In the span of 10 minutes, Pete illustrated with a very simple yet very realistic example the very type of serendipitous reuse that my article talks about. But if it his system had had a specialized interface, neither the browser, nor Excel, or anything else could have (re)used it.