For non-technical managers and business owners the term Application Programming Interface is an awful piece of jargon to comprehend, known to induce anxiety, despair and even outright capitulation whenever encountered in a business setting. The term’s commonly used initials, API, may not be as big a mental furball but they are no less baffling to put in context. But if explained properly (as I hope to do), the API is easily understood. Understanding it is key to understanding how the internet is evolving and shaping business today.
Simply put: If software applications (desktop, server, and web included) are like machines, then the API is like a rear hatch opening into the innards of that machine. While the machine has controls on its exterior designed to allow humans to control it, the API is an interface for other machines, a socket by which the machine can be manipulated, controlled, and effectively married to another machine. A human can push levers, turn valves, and read dials, but via the API another machine attach itself, mesh with the gears, the moving internals, and the heart of the machine.
In the software world the Application Programming Interface is not a human interface. It is a socket which allows another software program to connect with it. Through an API one software program can tap into another’s functionality to process information, pass along information, and extract information.
API’s are nothing new in the software world and they’ve around for along time and long before the internet. All kinds of software programs have been built with API’s that allow other software programs to mesh with them. While API’s weren’t something new, the world was faced with a couple of key challenges, in developing API’s that could be used over the internet.
Firstly, API’s for the internet had to be designed well enough so that computer programs could mesh with each other reliably over a worldwide network. This is not just simple communication over the internet, but accessing of other programs’ complex inner functionality across a spread out global network, with speed and reliability. It was easy enough to create API’s designed for use within an operating system but design of API’s over a large network (like the internet) had always been more of a challenge.
Secondly, the great minds behind the grand design of the internet thought it would be nice if these machine interfaces among web-based applications were “open” and relatively simple. They wanted a common set of standards so that no matter how the application was programmed, it’s functionality was exposed in a standard format. Ideally internet API’s would exist so that if a programmer wanted to write an application accessing a program across the internet, that programmer wouldn’t have to know that far-away program too intimately. He’d just have to know that the program had an API which was “open” and conformed to programming standards that he already understood.
So where are we now? Well, we’re making serious progress. Standards are not perfect but they are constantly being refined. And as internet infrastructure improves and broadband internet access proliferates, we are finding it not only easier to make use of web-based applications but also to mesh applications across the internet creating even more useful composite applications (which are sometimes called “mash-ups“).
In the past software platforms have always been founded on operating systems and underlying hardware. But with today’s internet based on open standards applications don’t need to know anything about the operating system and hardware at the other end. We are seeing the web emerge as a platform itself, independent of the operating system and hardware. And that is something new, and exciting.
Further understanding – You may get something out of this book “Object Technology: A Manager’s Guide”. Written for the non-technical business person it is a great introduction to foundations of software development and distributed applications over the web.