How Many Production Deployments Exist of APIs and Third Party Apps?

This is sixth part of ProgrammableWeb’s series on Understanding the Realities of API Security. It is based on the testimony offered by ProgrammableWeb’s editor-in-chief David Berlind to the ONC’s API Security and Privacy Task Force.  In the previous part -- Part 5 -- Berlind answers the following question posed by the ONC:  Are there API terms of use that include specific language for privacy and security?

The short answer, regarding the more than 14,000 APIs that ProgrammableWeb tracks in its directory, is yes, of course. There are thousands if not millions of deployments of such APIs and depending on the API, everywhere from one to thousands of third party applications using them. There are other API providers such as Google who are testifying today that will no doubt testify to this effect.

For example, one of the most important architectural benefits of an API is the way in which the application or process that consumes an API is “loosely-coupled” from the systems and processes that provide the API. One key benefit of such loose coupling is that, so long as the parameters that an application uses to interact with an API remain unchanged, the API provider is free to make changes to the underlying systems and processes that provide the API. For example, much the same way a power utility can substitute nuclear-generated power for coal-generated power without interrupting the functionality of common household appliances, an API provider can change the operating system that provides their APIs from Linux to Windows without disrupting the applications that consume that API.

This architecture has proven to be a major boon to the development of mobile applications, the majority of which rely on the loose-coupling principles of APIs to interact with their servers or, as some would say “to phone home.” When you consider the sharp proliferation of mobile applications (including the aforementioned NHL application) since the iPhone was first introduced in 2007, the grand majority of them consume APIs, thereby giving you some idea of the degree to which APIs have been put into production and the number of third party applications that rely on them.

In fact, when ProgrammableWeb was initially founded in 2005 and for many years after, it kept a record of all the applications -- then known as “mashups” -- that consumed Web APIs. But with the advent of app stores and mobile applications, it became quite evident that there was no way that ProgrammableWeb could scale its directory to match the growth of the various app store inventories. The “mashup directory” is therefore a part of the ProgrammableWeb directory structure that we no longer actively maintain because it’s not nearly representative of the true number of “mashups” that are currently available through app stores.

One additional point worth raising here is that the so-called “Internet of Things” will take this proliferation of APIs and the third-party applications that rely on them to an entirely new level. There is really no such “thing” (including a great many medical and fitness devices) as a “thing” on the “Internet of Things” that doesn’t have an API so that applications and other processes like microservices can interact with it. When you start to consider how every appliance, light bulb, car, and even the buttons on your shirts will be connected to the Internet, it isn’t difficult to imagine the orders of magnitude to which APIs and the third-party applications that work with them will be put into production.

In the next part -- Part 7 -- of ProgrammableWeb’s series on Understanding the Realities of API Security, ProgrammableWeb editor in chief David Berlind answers the following question posed by the ONC:  What Are The Perceived and Actual API Security and Privacy Concerns?

David Berlind is the editor-in-chief of ProgrammableWeb.com. You can reach him at david.berlind@programmableweb.com. Connect to David on Twitter at @dberlind or on LinkedIn, put him in a Google+ circle, or friend him on Facebook.

Comments