Application programming interface

API redirects here. For other uses, see API (disambiguation).

An application programming interface (API) is a set of definitions of the ways one piece of computer software communicates with another. It is a method of achieving abstraction, usually (but not necessarily) between lower-level and higher-level software.

Contents

1 Description 2 History of the acronym API 3 Example APIs 4 See also

Description

One of the primary purposes of an API is to provide a set of commonly-used functions—for example, to draw windows or icons on the screen. Programmers can then take advantage of the API by making use of its functionality, saving them the task of programming everything from scratch. APIs themselves are abstract: software that provides a certain API is often called the implementation of that API. In many instances, an API is synonymous with an SDK, or software development kit. An SDK may include an API as well as other tool/hardware, so the two terms are not strictly interchangeable.

For example, one may look at the task of writing "Hello World" on a screen at increasing levels of abstraction:

1. Do it all yourself:
   1. Draw, on graph paper, the shapes of the letters "H", "e", "l", "l", "o", "W", "o", "r", "l", and "d".
   2. Work out a matrix of black and white squares that look like those letters.
   3. Devise a way to program the CPU to put this matrix into the display adapter's frame buffer.
   4. Set the graphics card up to scan its frame buffer to generate the correct signal.
2. Use an operating system to do some of the work :
   1. Load a data structure called a "font" provided with the operating system.
   2. Have the operating system display a blank window.
   3. Use an operating system service to draw the text "Hello World" to the window with the font.
3. Use an application program (which uses an operating system) to do all this hard work:
   1. Write a text or HTML document containing the text "Hello World".
   2. Open the document in a web browser.

Obviously, the first option is much more complicated than the subsequent options. In addition, it is impractical to use the first approach to present a substantial amount of information, such as an encyclopedia article, on the screen, whereas the second approach makes the task much easier, and the third approach basically requires only that you type "Hello World." However, higher-level APIs often lose flexibility; for example, it would be much more difficult in a web browser to rotate text around a point with blinking outlines, something that could be done at the lower levels. This difference is a typical example of the trade-offs encountered by choosing to use an API.

APIs are as essential to computers as electrical standards are to the home. One can plug a toaster into the wall whether at home or at a neighbour's house, because both houses conform to the standard electrical interface for an electrical socket. If there wasn't an interface standard, one would have to bring a power station along to make toast! Note that there is nothing stopping somebody else coming up with another standard; a European toaster will not work in the US without a transformer, just as a program written for Microsoft Windows will not work directly on a UNIX system without an intermediate API adapter such as Wine.

There are various design models for APIs. Interfaces intended for the fastest execution often consist of sets of functions, procedures, variables and data structures. However, other models exist as well, such as the interpreter used to evaluate expressions in ECMAScript/JavaScript. A good API provides a "black box" or abstraction layer, which prevents the programmer from needing to know how the functions of the API relate to the lower levels of abstraction. This makes it possible to redesign or improve the functions within the API without breaking code that relies on it.

Two general lines of policies exist regarding publishing APIs:

1. Some companies guard their APIs zealously. For example, Sony makes its official PlayStation API available only to licensed PlayStation developers. This is because Sony wants to restrict how many people can write a PlayStation game, and wants to profit from them as much as possible. This is typical of companies who do not profit from the sale of API implementations (in this case, Sony breaks even by selling PlayStation consoles and takes a loss on marketing, intending to make it up through game royalties created by API licensing).
2. Other companies propagate their APIs freely. For example, Microsoft deliberately makes most of its API information public, so that software will be written for the Windows platform. The sale of the third-party software sells copies of Windows. This is typical of companies who profit from the sale of API implementations (in this case, Microsoft Windows, which is sold at a gain for Microsoft).

Some APIs, such as the ones standard to an operating system, are implemented as separate code libraries that are distributed with the operating system. Others require software publishers to integrate the API functionality directly into the application. This forms another distinction in the examples above. Microsoft Windows APIs come with the operating system for anyone to use. Software for embedded systems such as video game consoles generally falls into the application-integrated category. While an official PlayStation API document may be interesting to read, it is of little use without its corresponding implementation, in the form of a separate library or software development kit.

An API that does not require royalties for access and usage is called "open." The APIs provided by Free software (such as software distributed under the GNU General Public License), are open by definition, since anyone can look into the source of the software and figure out the API. Although usually authoritative "reference implementations" exist for an API (such as Microsoft Windows for the Win32 API), there's nothing that prevents the creation of additional implementations. For example, most of the Win32 API can be provided under a UNIX system using software called Wine.

It is generally lawful to analyze API implementations in order to produce a compatible one. This technique is called reverse engineering for the purposes of interoperability. However, the legal situation is often ambiguous, so that care and legal counsel should be taken before the reverse engineering is carried out. For example, while APIs usually do not have an obvious legal status, they might include patents that may not be used until the patent holder gives permission.

History of the acronym API

The OED defines API in part by saying that IBM developed the API concept in the 1960's. The OED calls it a "high level programming language" which differs from the description in this article slightly, or in any case, is not as nice. c.f interface to further clarify the meaning.

Example APIs

• The PC BIOS call interface
• Document Object Models of various applications, such as HTML
• The Single UNIX Specification
• The Microsoft Win32 API
• The J2EE Java 2 Enterprise Edition APIs
• ASPI for SCSI device interfacing
• The Carbon and Cocoa APIs for the Macintosh OS
• The various APIs which make up Microsoft's DirectX
• Simple DirectMedia Layer (SDL)
• The Linux Kernel API [1] (http://kernelnewbies.org/documents/kdoc/kernel-api/linuxkernelapi.html)

See also

• Ontology (computer science)
• Application binary interface (ABI)
• Plugincs:API

de:Application Programming Interface et:API es:API fr:Interface de programmation ko:API hu:Alkalmazásprogramozási felület nl:Application Programming Interface ja:Application Programming Interface pl:API (informatyka) ru:API zh:编程接口