Instant API! Just add water.

A decade ago I was a software engineer at ON Technology in Cambridge--working on the Meeting Maker product line. One day the requirement came down that an API was to be built and offered to our customers as a product extension. The turmoil that resulted amongst the engineering ranks was astounding. Instantly, this seemingly minor task became the proverbial hot potato. Why? Because Meeting Maker was at the time a closed and extremely complex network-based system with an arcane custom database and very lightweight datagram transport protocol. The system was designed to be closed in order to be as efficient as possible—a very valid design given the fact that the target architecture was Apple Macs. That made the task of building a flexible and easy-to-use programming interface to this complex architecture a daunting task indeed.

Fast forward ten years. Web 2.0 user interfaces, whether they are AJAX or Flash, require HTTP-based access to the host systems that supply them with information. This design yields an ‘Instant API’ in the sense that other systems can integrate with the host systems using the same HTTP-based access points. Viola! an Instant API.

Choosing an open, well-documented protocol for your communications to and from the host systems is therefore an extremely important design decision. For FindFreeTime I chose to use XML-RPC, a simple XML-based communications protocol. Most of our ‘method calls’ to our API embed entities (people, proposals, etc) as escaped XML in struct members.

I suspect that the profusion of mashups and other “feats of interoperability” that Web 2.0 services now show off have AJAX and Flash user interface designs to thank for their success.