Amid the buzzwords of corporate technology, we often come across the concept of an Application Programmer Interface, or API. Sometimes this relates to extras that you get with a proprietary product ("If you want to customise it, you can buy our API"), or they're listed under the "supported protocols" section in the spec sheet. But just what is an API, and why would we want to have one?

An API is basically a rigidly defined set of instructions and interactions that can be used by two programs (typically a client program and a server application) to interact and co-operate in some way. In the most basic form, the manufacturer of (say) a phone system or an accounting package may publish a set of system calls that allow a programmer to interface from their code into the manufacturer's equipment. So if you're writing a Windows program that pops up the details of a caller when your phone rings, it would use the PBX's API to communicate with the phone system in order to spot calls when they arrive.

Proprietary APIs
A proprietary API is specific to one device or, more likely to a number of devices within a particular manufacturer's product range (after all, they wouldn't want your home-built, API-integrated software to be tied to their entry-level product when they come to try to upgrade you to the more expensive model). Note that this doesn't mean that the API doesn't support standard protocols (many proprietary APIs use HTTP as the transport protocol and XML as the information wrapper), just that in its basic form, the layout of the data flying to and fro is device- or vendor-specific.

Although often motivated by the desire to tie the customer to the vendor's own product range, there are often less Machiavellian reasons for adopting a proprietary API – namely when there isn't a standard one that supports everything the system can do. After all, standards tend to lag behind the state of the art, and so it's often necessary to adopt proprietary interfaces into functions that aren't yet considered by the standard.

Standard APIs
For the customer, the best sort of API is a standard that's been adopted across the industry, since this gives you a choice for your initial purchase and ensures that you're not locked into a particular vendor's brand of equipment for life. Unfortunately, few of the common APIs one comes across are official "standards" (i.e. administered and moderated by an independent body); on the plus side, though, there are plenty of APIs out there which, although generated in the first instance by vendors, are widely accepted as the closest thing that we'll get to a standard.

The two most common "de facto standard" APIs in use are the Telephony API (TAPI) and the Mail API (MAPI). Both devised by Microsoft (in collaboration with Intel in the case of TAPI), these interfaces provide a way to write client-server systems that aren't tightly coupled with the specific systems for which they are written. So if you write a program that uses MAPI to send email messages, it'll work with any MAPI-compliant mail server rather than just the one you wrote it for. Similarly with TAPI – if you have a call centre system that uses a particular version of the TAPI standard, it'll interface to any telephone switch that provides an interface to the same (or later) version of TAPI. There is, of course, a whole set of different APIs – alongside MAPI and TAPI there are others, most notably CAPI (Common ISDN API) and SAPI (Speech API).

What form does an API take?
Part of the point of an API is that it's an interface provided for programmers – that is, it's implemented as some kind of function library that can be called directly from whatever programming language the developer writes in. So under Windows you'd expect there to be a DLL or ActiveX component whose functions you can dip into, without caring how the actual communication between the library and the remote equipment is done. This is certainly how the "standard" ones mentioned above work, for instance.

Proprietary APIs vary in their representations, though. Some are done like the "standard" ones we've just mentioned, and are provided to the developer as a function library. Some, on the other hand, require the programmer not just to call functions but to write some middleware to "glue" the program to the back-end system. The missing link may, for example, be that the developer has to write some code to make a TCP connection to a PBX and parse the data that's flying down the connection in order to pull out the data that's required. By definition, proprietary APIs vary in their representation (and usefulness).

When making any significant corporate purchase, it makes sense to consider how the new product can interface to other systems – either existing ones or potential future purchases. As client-server computing becomes more popular it's common to see organisations requiring support for the relevant APIs (e.g. TAPI for telephone systems or MAPI for mail servers) in order not to restrict future purchasing decisions for either the client or the server component of any system. There does come a point, though, where it makes sense to consider accepting a proprietary API – and that point is where the device you're purchasing does more than the standard APIs are able to support.