Public API Driven Systems Are Cool But…

I’ve become a fan of cloud software that helps to build personal information systems. I liked Yahoo Pipes when it was alive even though it was hard to use. More recently I’ve been using IFTTT, which stands for If This Then That, and Numerous. IFTTT acts as a conduit for information from a cloud system to another one. Using a simple interface, an end-user builds a script, called a recipe by Numerous. The end-user selects a Trigger Channel, in other words a source, any variations on the channel called Triggers, an Action Channel, which is the sink or destination, and parameters that accompany that channel. This builds an IF-THIS-THAN-THAT statement which runs automatically. For example, it’s easy to build a script that detects a new entry in a blog and automatically tweets a link to it on Twitter.

Numerous, on the other hand, is designed to create personal dashboards but allowing numerical data to be pushed to a value called a Number. Some examples of this are the number of Facebook friends or Twitter followers someone has at the moment. It’s also possible to create a Number that acts as a container for information pushed to it. Using the Numerous API, it’s possible to write a script that does useful actions such as send the number of daily customer interactions from a CRM system to a custom Number. Combined with IFTTT, it’s possible to build some really useful dashboards without programming. For example, I have a set if IFTTT recipes that increments a Numerous Number that shows the number of monthly meetings I’ve had so far based on my Office365 calendar. At the beginning of the month, another IFTTT script resets this to zero.

It’s possible for an average knowledge worker to build these types of systems without any special knowledge or programming talent because of the rich set of public APIs so many mobile and cloud applications expose. IFTTT exploits these APIs in order to create their Channels, which are really collections of API calls after all, and Triggers. Numerous, on the other hand, exposes an easy-to-use API that allows anyone (such as IFTTT) to push information to a Number.

While API driven software makes it very easy to create complex systems from mobile and cloud apps, companies like IFTTT don’t control the public APIs they tap into. Changes to those public APIs can vastly change the behavior of these systems and even their ability to operate altogether. For example, a little while ago much of the LinkedIn Trigger Channel functionality began to disappear from IFTTT. Now, LinkedIn is only an Action Channel or destination. This means that IFTTT recipes can only post to LinkedIn whereas they used be able to pull information from LinkedIn. IFTTT is completely at the mercy of LinkedIn for interactions with their software. There used to be a number of pre-made recipes for pulling job listings from LinkedIn and stuffing them into an email or Evernote. Now, those have all disappeared.

This is not confined to LinkedIn by any means. Recently Google decided to shut off access to what had been an unofficial public API for autocomplete. Yes, it was unofficial but also widely used. By closing it off, the applications that used it suddenly broke. Without formal agreements in place, there was little the software developers who relied on it could do but complain.

So, while we all get excited about the new API economy and the prospect of easily assembling software from public APIs, remember the Achilles Heel is control. When someone else controls key features of an application, it can be broken at any time leaving a developer with no recourse other than to suck it up.