Cameron Laird's personal notes on APIs

Exposure of APIs is one of the great themes of the early 20-teens (along with, let's say, virtualization, Cloud, big data, pervasive computing, digital-physical binding, mobility, ...) [references]. Along with these others, it intrinsically binds technology and business model. I explain:

Up to approximately 2000, "API" was generally understood as language-dependent. Note, incidentally, that the Wikipedia API page makes a point of disclaiming that "the scope of meaning is usually determined by the context of usage"; among naive working programmers, for instance, it's common to hear "the API" for "entry point". Language-independence generally implicated RPCs [reference]. By 2010, API largely appears as a contrast to application as a business entity: it is possible to charge for API service as legitimately as one charges for applications. To a large extent, humans consume applications, while computers consume APIs.

As an implementer, I've long held to the prejudice that wire protocols have the potential to be virtuous/useful/open/..., while APIs are fragile and even imperialistic. I haven't examined that sentiment deeply. In the business context of 2010+, of course, "API" often betokens "RESTish service" which, for me, qualifies as a wire protocol. Another personal connection: at least some of the strategists at Gensym, Mathematica, ... had the vision by the early 1990s--roughly concurrent with the blossoming of the Web--that their platforms could support sustainable Internet-transported service offerings. This never did happen in any satisfying way; I've always believed that the absence had more to do with biased business practices in IT during the '90s, than any confusion or distraction from the Web. I wrote obliquely about the programming of this in a 2003 book review on BEEP.

I see REST and allied SaaS technologies as secondary to the relative vigor of API activity in the 2010s; most of the change is in business attitude.

As a devop who's moved back and forth between application development and automation numerous times over the last decades, I feel particularly comfortable designing and implementing APIs for the 2010s, that is, the Web's automation interfaces.

[Contrast ABI and API.]

In this interview, Ev Kontsevoy [reference] rightly observes, "Selling APIs did not sound like a hot business plan in 2009. APIs were usually seen as a free add-on to a revenue[-]generating product, not as a product by themselves. Amazon Web Services and Twilio helped changed that." A few days earlier, coincidentally, Brenda Michelson [reference] had published a profile of Bechtel's API initiative.

I resist for now the urge to connect to academic analysis of REST and more general SaaS. I do appreciate, though, this rumination by the ever-insightful Armin Ronacher on HTTP techniques.