Application Programming Interface
I never studied computers, formally at least. My Dad was, and is, a software quality assurance engineer. My first memory of computing was an LED display of a teddy bear on his screen in the mid-late 1970's, when he used to work at Applicon, an early CAD/CAM technology company on Route 128 in Massachusetts. My next computer memory was designing a maze video game for the TRS 80 with my Dad and brother Jonas. In addition to placing the pixels for the shape and color of each alien enemy, we had to choose names of levels. One was "Estra" after my grandmother whose name was Esther. I thought we were being quite clever at the time, manipulating the interface of the game based on our personal preferences. I never pursued technology with formal training, and instead went on to a life in the theatre, as a child actor, then drama student as a literature major at Columbia. In 1993, working as the archivist for Robert Wilson's Byrd Hoffman's Foundation , I stumbled onto CD-Roms and later the Internet as a means of communicating complex multimedia stories. The prospect of using the Web as a medium for advertisers was not that far afield.
In February 1995, I worked as an HTML programmer for Agency.com, specializing in creating nested tables that had just been released as a spec by Netscape. I remember working on a catalogue for HBO Video, meticulously framing each image and description to make it easy for visitors to navigate through the video library. At the time, there were few professional HTML coders which meant that I could command $75/hour to do what would become commodified by programs like FrontPage within months. In any case, my role at that moment in time (which was coincident with the launch of akebono.stanford.edu aka Yahoo!) was to manually encode static information for individual visitors. It was incredibly exciting despite how lame it sounds in retrospect.
APIs are the new HTML
But now, in tackling the concept of API, even as it relates to something familiar like Internet Advertising, I am intimated by the history of professional, enterprise computing. It seems like the antithesis of my own amateur technology tinkering. For me, APIs are IBM mainframes and Microsoft SDK's, arcane languages of translation between hardware and software. This was hard-core C coding, the kind you learned at MIT or CMU, not what you picked up on your own. But there is another definition of APIs that is emerging in this current Web 2.0 landscape, one that has evolved into (regressed back to?) precisely the amateur, family-oriented activity that I am almost embarrassed to describe as technology.
It is now 10 years later, and information has now auto-propogated itself to the point where a new kind of API is required, one that enables users to connect and communicate with eachother rather than with the information itself. Web services are essentially apertures that refract user driven data towards a specific end. This would seem to have little to do with the heritage of the original Microsoft Windows API which enabled professional programmers to develop desktop applications on top of the Windows platform. In late 1999 I sat down with a key figure and evangelist of the Windows platform and API, Brad Silverberg who had recently left Microsoft, and after taking some time off, started a new venture fund called Ignition with the belief that wireless networks would create new platform opportunities. It would not be hyperbole to describe Silverberg as the chief developer of the most valuable technology platform in history, Microsoft Windows 95. I asked Brad to describe what made a platform successful and he replied without pause:
- distribution: first and foremost you need to have a critical mass of customers using the platform
- tools: you need to have good tools for developers to build applications that can easily leverage the key features and functionality of the platform
- case studies: you need to have examples of developers who are making good money selling applications leveraging the underlying platform
As of 2005, the Internet has replaced the desktop PC as the primary platform for APIs. Unlike Microsoft and the desktop, however, nobody controls the web as a platform; although certain companies do oversee enormous pools of user data and have the opportunity to direct such traffic as they see fit. The talk of Google and Yahoo! (and now IAC) as web platforms center around their ability to recycle users through complex interconnecting networks of search, email, dating, travel, shopping, local services and more. This is the web version of the gated AOL community circa 1996. Ironically, AOL is now desperately racing to open their proprietary (Rainman) environment to a public web site (AOL.com) before Yahoo! fully eclipses its relevancy.
Virtually all of the major Web 2.0 platforms (GOOG, YHOO, IACI, AMZN, EBAY) recognize how critical it is to engage their users in the act of media production, and therefore are (in different ways) releasing APIs that stream their consumers' meta data. Such data is not simply theirs for redistributing, but rather needs to be the byproduct of some other functionality such as Amazon wishlists, Flickr tags, or EBay auction trends. Along these lines, the value of a Web Service API is tied to its ability to convert granular feeds of individual data into useful social media contexts. It is not particularly helpful to think of APIs as simply conduits of data, since the way in which API’s package data are frequently as valuable as the data itself. In order to access Flickr’s API, for example, you need to choose whether to organize the data by groups, contacts or favorites. Central then to the evaluation of an API is to what extent it performs high level operations on low level data, and how interesting the ensuing abstractions are to a broad community of users.
A relevant example is my Flickr Zeitgeist stream to the right of this post. A few weeks ago, I found this simple application that allows you to syndicate a photostream based on your own and/or other people’s photos. Once you choose, it creates HTML, which you can simply copy and paste within your blogging system. Curiously, the exposure of my images to a wider audience has pressured me to upload and tag more photos to my Flickr account than I would otherwise. Call this the blog-narcissism complex: although I am only sharing my Flickr portfolio with the handful of visitors like you that come to my blog, I feel responsible to provide you with the richest and most dynamic feed of pictures possible.
For a more comprehensive list of platforms, APIS and applications, I have pulled together the following set of useful links:
Amazon - Data source - Example
Del.icio.us - Data source - Example
EBay - Data source - Example
Flickr - Data source - Example
Google - Data source - Example: None public as of now.
Yahoo! - Data source - Example: None public as of now.
While most of these platforms (save perhaps for del.icio.us since Flickr now has Yahoo!'s reach) have achieved ample distribution and provide solid tools for application development, none of them have as of yet produced a profitable web service application to fulfill their platform requirements. One could argue that EBay does this every day as part of their seller network, or that Google has enabled many profitable media enterprises (ie my pals Jason, Gordon and Shawn at Weblogs), but we have still yet to see fully formed businesses leverage these platform APIs and thrive as stand alone entities. These will likely emerge in the next 3-6 months.
In the meantime, the goal was simply to establish the API as a key component of media futures, specifically as the hinge between the algorithm that processes raw human meta data and the moment of alchemy that occurs when you discover something you didn't even know you were looking for, courtesy of some people that you didn't even know that you knew.
Recent Comments