API stands for Application Program Interface; you knew that, of course. APIs are not new but they are crucial in knitting together the services and technologies of Web 2.0 (aka Bubble 2.0).
We people use a GUI (Graphic User Interface) to tell computer programs what we want them to do. An API is the way one program tells another what it wants done. A program which supports APIs can, relatively easily, be knitted into the function of other programs. It can be a building block.
Much of the initial success of the Macintosh depended on the extensive set of APIs Apple provided to developers so that those developers could build the functionality of the Mac interface into their own applications.
Before the Mac, on DOS, for example, or the Apple II, each program implemented its own idiosyncratic user interface. On the Mac a window was a window was a window; the mouse worked the same way in every program; pull down menus were predictable. This commonality was achieved because the application programs – the word processors, spreadsheets, and drawing programs – DIDN’T implement their own user interface; instead, each program that wanted a window opened or a menu dropped down, used an API to request the Mac OS to perform the required function.
Developers were able to produce easily-mastered and very graphic programs quickly because so much nitty-gritty functionality could be accomplished simply by invoking the APIs. Users gained both from the quality and quantity of new applications available AND commonality of interface elements which made learning new programs much easier than it had ever been before.
The APIs were marketed brilliantly to developers by the now-famed Apple Evangelists including Guy Kawasaki, Alain Rossman, and Mike Boich. Apple gained a temporary resurgence after being buffeted by the first IBM PCs.
Microsoft is nothing if not a fast follower. Microsoft application developers quickly mastered the Mac APIs and produced a brand new spreadsheet – Excel – for the Mac. Then Microsoft built a new operating system – Windows – which had the APIs to support applications like Excel, whether written by Microsoft or others. Even the abominable first Windows 1.0 was API rich.
In years to come, much of the antitrust discussion about Microsoft was about APIs. Did the developers of Word and Excel have earlier access to new Windows APIs than the developers of competing applications? Does Windows have secret APIs which only Microsoft application developers know about? APIs clearly mattered.
Some day I’ll blog about the great VIM – MAPI showdown I posted about the great VIM-MAP showdown here. MAPI was Microsoft’s set of Messaging APIs (I was responsible for Microsoft Mail and Exchange at the time) ; I forget what VIM stood for but it VIM (Vendor Independent Messaging) was the product of an ABM (Anybody But Microsoft) alliance of Apple, Lotus. Novell, and IBM. MAPI won; very few people run cc:Mail or Lotus Notes as mail clients today. APIs matter.
Programs and operating systems which have useful APIs become “platforms”. Developers of other programs incorporate their functionality and, in doing so, broaden the market for the product which has become a platform. Not only Windows but also Word and Excel and Outlook have APIs which expose their functionality to outside developers.
Now let’s get to Web 2.0. A service like Google or Yahoo or FeedBurner or del.icio.us is just programs running on servers. The service providers can expose and publish APIs for the programs that run on their servers. When they do this, the services have a chance of becoming platforms for other services developed by other people.
Becoming a platform will be the road to fame and glory - not to mention riches - for many Web 2.0 services. Success will be determined by the usefulness of the underlying service and how attractive it is to third party developers and to other services. And, of course, how well it is marketed to developers.
Google Maps is a great example. Sure the maps and photos are great themselves. But, because Google was smart enough to create APIs, the map functionality is being built into zillions of applications which overlay the map data with something else useful.
I blogged the other day about how useful the FeedBurner and FeedBlitz APIs were to publisher dotHill Press when we wanted to make it possible for users to subscribe to the serialization of hackoff.com starting with the first episode no matter how far the serialization has progressed.
In this case FeedBurner and FeedBlitz already had ALMOST all the functionality we needed; but it probably would have been a long time before there was enough demand for the precise pieces we needed to make it worthwhile for FeedBurner and FeedBlitz to add them to their base functionality instead of some of the other things they are working on. Their APIs made it possible for us to develop the missing piece with one hard day’s work. We didn’t have to leave FeedBurner for a competitor who didn’t offer the other things we like about FeedBurner. Feedburner and FeedBlitz became a better platform for book serialization without having to do additional development work because they were smart enough to build and promote APIs.
Today Web 2.0 is made up of thousands of small service providers as well as few large ones. Many of the small services will never reach a critical mass of usefulness by themselves. However, useful services with useful APIs will grow because of the investment that other service providers make in extending and incorporating their data and functionality.
APIs matter whether you’re a Web 2.0 entrepreneur or a Web 2.0 investor.
Coming soon in a future blog: why some services don’t want APIs and do everything they can to avoid being useful or used by other services.