Recent moves by Twitter and Facebook have emphasized yet again that the great leverage of using other online services' APIs is fraught with risk.
Those of us who have been in the software business for a few technology generations have witnessed some major changes in the way applications are architected. This point was brought out last week in a blog post by Tarek Ziade, which attracted significant commentary both on Google+, where Ziade originally posted a sketch of his ideas, and on his own blog, where he expanded on them.
From a pre-Web architecture of thick client apps talking to databases across a wire, we evolved into the pattern that has prevailed from roughly the turn of the century. This saw the development of heavyweight frameworks on the server side, talking to databases, and lots of tools there to generate templates and produce rich web pages, which came back down the wire. The client was a thin layer built on Cocoa, GTK, wxWindows, or even HTML / JavaScript.
We have been seeing this architecture morph into something new over the last year or two. The server layer is thinning out -- in the most extreme case it becomes merely a message-passer and format-translator sitting in front of the database. The client is fattening up to handle all of the rendering tasks and sometimes even some of the business logic. (See the two diagrams in Ziade's blog post.)
With this shift, and with the expectation of always-on connectivity and mobility, apps are relying more and more on web services provided by others in the form of APIs. Such a strategy can provide enormous power to an app -- leveraging man-decades of others' development work and terabytes of their data. But over-reliance on others' APIs is dangerous, in that the API owner can revoke access for competitive reasons, or can change the ground rules at any time.
Living and dying by the API
Developers who were (and are) reliant on Twitter's APIs learned this lesson late last year, when Twitter tightened its terms of service in an attempt to funnel more traffic to its own website (and ads).
More recently Facebook shut out Yandex, Russia's largest Internet company, from its social graph. Yandex had developed a Siri-like answer engine dubbed Wonder, which attempted to answer users' questions by mining their social feeds. It seems that the social giant judged that Yandex had been operating a search engine over its data, which is forbidden by the terms of service.
In the latest demonstration of the precarious position occupied by apps dependent on another's data, Facebook shut out Vine, Twitter's new 6-second-video service, from accessing users' friends lists in order to search for and invite more users to the service. (Vine had other problems with its launch as well.) The Buzzfeed link above lists the history of the last few months' worth of Twitter/Facebook back-and-forth API blockades, some of them involving Instagram. In this latest block, Facebook accused Vine (not by name) of "[bootstrapping] their growth in a way that creates little value for people on Facebook," because Vine wasn't reciprocally sharing its own friends' lists.
The lessons should be obvious. By all means use the power of public APIs. But read the suppliers' terms of service with great care. And don't pin your business irrevocably on somebody else's code without a carefully thought-out fallback strategy.