How web and browser APIs fuel the API economy

When developers write code, rarely do they start from scratch. For example, if a software company is going to create a word processor that runs on Microsoft Windows, the developers of that word processor would make use of various features already built into Windows instead of attempting to recreate those features. 

This begins with the most basic part of Windows--the windows themselves. Prior to the existence of Windows and other graphical operating systems, if a programmer wanted to present a resizable box on a screen complete with a title bar and buttons for minimizing, maximizing or closing that box, s/he would have to write thousands of lines of code from scratch. From one application to the next, this “windowing” capability might work differently, as each programmer might have a different idea of how such windows should look and feel. But when Microsoft began to offer Windows as an operating system, it also provided developers with a means--an API--for drawing those windows on the screen with only a few minutes of work.  

In this context, Microsoft provided the API as means to access the windowing service in the Windows operating system, and the developers of the thousands of applications that run on Windows “consumed” that service through its API. Those developers didn’t have to write code to draw the title bar of the window nor provide for the resizing features of the window. Instead, those features were inherited by any window that was created using the windowing API found in Microsoft Windows itself. 

Likewise, programmers don’t have to write thousands of lines of code for storing individual bits and bytes onto a computer’s hard drive—Microsoft Windows includes a specialized API for doing that, as well. Within their code, programmers simply make a reference to that API (more commonly referred to as “calling an API”), supplying it with the data they want Windows to save to the hard drive.  

Many APIs expect such inputs, otherwise known as parameters. The windowing API, for example, requires certain parameters; it needs to be fed the exact coordinates of the top left and bottom right corners of the window its about to paint. Then, you guessed it, the windowing service in Windows takes care of the rest.

In much the same way that the electrical socket abstracts the complexities of the electrical service that, say, your vacuum cleaner consumes, when APIs hide all of the complexities, internals and logic required to complete a task (such as painting a window, saving data to a hard drive, translating a word, reading the current location from a GPS receiver or presenting an interactive map), those APIs are serving as a layer of abstraction to the underlying service. 

The extent to which APIs make oft-repeated yet complex processes highly re-usable with just a single or few lines of code is fundamental to developer productivity, modern day application development and the API economy. 

Using this kind of a model, programmers are significantly more productive than they would be if they had to write the code from scratch. They don’t have to “reinvent the wheel” with every new program they write. They can instead focus on the unique proposition of their applications while outsourcing all of the commodity functionality to APIs. 

Take credit card processing, for example. There isn’t a whole lot of room for innovation in this area-- it is unlikely that custom-written credit card processing routines are going to make, say, one taxi cab service more competitive than the next. It would therefore be a waste of time for developers working for the taxi cab service to build a credit card processing service from scratch. The return on investment compared to simply outsourcing that credit card processing to a best-of-breed API provider (like Stripe) makes the custom-code alternative financially infeasible.

The API economy’s growth is thusly driven by service providers that compete to address this thirst for greater developer productivity by packaging commodity and, often, complex functionality into easily reused API-based components. For each of the various types of functionality that can be invoked via API (such as credit card processing, mapping, navigation and translation), there are often multiple API providers vying for the attention of application developers. In turn, as more componentry is supplied in the form of API-based services, the API economy is accelerating the trend toward a world of applications that are primarily composed from off-the-shelf APIs. 

The net result of the API economy’s vicious and accelerating circle is that applications that once took months or years to build now take days or weeks or even hours. Developers are not only more productive, but the time it takes a business to make an application available to its customers is dramatically reduced. In turn, those customers benefit from shorter development cycles because the applications they use are being updated with new and innovative features more frequently.

As has just been suggested, APIs aren't limited to Windows, nor are they confined to what can be found in the same system (such as a desktop, tablet or a server) that runs API-consuming applications. Much the same way an application can call a hard drive API from Windows, a taxi-dispatching application can call a credit card processing API like Stripe from across the Internet. In other words, developers can also consume APIs that are offered by remote systems and devices that are reachable through a network. That network can be a private network, like the ones found in homes and businesses, or, it can be a public network like the Internet.

Whereas the computer logic behind the API that saves the data to a hard drive is often local to the personal computer that’s also running the API-consuming application, this type of networked API works a little bit differently. Using our taxi-dispatching application as an example, all the logic for processing credit cards runs on Stripe’s remote systems which in turn are abstracted by Stripe’s credit-card processing API. 

Just as the electrical socket in the wall represents the endpoint of the electrical system into which electricity-consuming devices are plugged, APIs involve an endpoint—essentially, a socket into which consuming applications are plugged. The number and types of devices that can be plugged into electrical sockets are limited only by the imaginations of inventors (and the capacity of the utility), and, likewise, the number of applications that can take advantage of the functionality abstracted by an API’s endpoint is limited only by the imaginations of developers and the capacity of the API provider’s infrastructure. Case in point: It wasn’t long after Google offered an API for Google Maps that thousands of third-party developers stepped forward with unique and innovative applications that consumed the API, incorporating Google’s mapping functionality directly into their apps.

It is for this reason that APIs are often referred to as an engine of innovation. The Google Maps API is just one API that spawned a cycle of innovation that continues to this day. The founders of the Instagram photo-sharing service might never have succeeded had it not been for the Facebook API that allowed Instagram users to broadcast their latest photos to their friends on Facebook. It isn’t hard to imagine the sort of innovation that will be inspired by the millions of APIs that will one day be a part of the API economy.

This is part of our series What Are APIs and How Do They Work? In part 4, we’ll cover the API principles of abstraction and why they are so beneficial to API providers.