Application Programming Interface

APIs aren't difficult to create, but they can be difficult to learn, says analyst Larry Perlstein at Stamford, Conn.-based Gartner Group Inc.

Application developers and vendors must constantly be thinking about whether their APIs will be understandable to future developers. "An API is useless unless you document it," he says, yet some vendors have left APIs undocumented.

APIs as Competitive Weapons

If a company wants to frustrate developers, it might keep its APIs secret or change them rapidly. Microsoft Corp.'s many critics, including government lawyers and competitors, have accused the company of engaging in such practices. Andrew Schulman, who ferreted out several hidden APIs in Windows in his book Undocumented Windows, is now a consultant for Caldera Inc. in Orem, Utah, which has an antitrust suit pending against Microsoft. Instead of hiding APIs nowadays, Schulman says, "Windows has a kind of 'kitchen sink' architecture into which Microsoft can keep dumping new APIs. This API 'churn' is in part an attempt to keep Windows a 'moving target' so that it doesn't get cloned."

Judge Thomas Penfield Jackson cited a similar criticism in his Nov. 5 findings of fact in the Department of Justice's case against Microsoft: "Attempting to clone the 32-bit Windows APIs is such an expensive, uncertain undertaking that it fails to present a practical option for a would-be competitor to Windows."

But Perlstein says Microsoft competitors may be more jealous than justified in criticizing how the company handles the Windows APIs. Some "back doors" may be oversights. Microsoft spokesman Jim Cullinan adds that Microsoft is constantly improving Windows and updating and adding APIs, because to slow the pace of improvement would mean falling behind

APIs and You
Application programming interfaces (API) can seem vague, and vendors or developers might wave them around like magic wands that solve all problems. But they really can be very simple and powerful. Everyone uses something similar to APIs in daily life all the time to request access to services. APIs offer less flexibility than open source code but more flexibility than completely closed applications.		IMAGINE YOU HAVE THREE NEIGHBORS: Closed Carl, Open Oscar and API Annie. Each of you is like an application. Like any neighbor, you sometimes need to borrow things from your neighbors, such as a lawn mower. This is the equivalent of applications integrating.
		CLOSED CARL simply won't provide you with any services. He mows his own lawn behind a high fence. Not only is there no way to ask him for anything, you can't even walk onto his property to try because his fence has no gate. An application like Closed Carl exposes no source code or APIs.		OPEN OSCAR is the opposite. He's so open that he will let you freely enter his yard whenever you'd like and even tinker with his mower so it suits your needs exactly. Of course, once you've changed the design from what's documented in the manual, you've entered the mower maintenance business. An application like Open Oscar has open source code, giving you free reign if you want it.		API ANNIE will let you borrow the mower if you ask in the right way (by calling the "getMower" API in your own application code). You can't enter the gate without that request, and you can't open the mower and tinker with it. But you can get the service of mowing as needed. Applications like Annie, which are closed but have APIs, are the most common in enterprise settings.

See additional Computerworld QuickStudies