Application programming interface

This article may require copy-editing for grammar, style, cohesion, tone or spelling. You can assist by editing it now.  (December 2008)

In computer science, an application programming interface (API) is an interface defining the ways by which an application program may request services from libraries and/or operating systems.^[1][2][3] An API determines the vocabulary and calling conventions the programmer should employ to use the services. It may include specifications for routines, data structures, object classes and protocols used to communicate between the requesting software and the library.

An API may be:

• Language-dependent; that is, available only in a particular programming language, using the particular syntax and elements of the programming language to make the Application Programming Interface convenient to use in this particular context.

• Language-independent; that is, written in a way that means it can be called from several programming languages (typically an assembly or C interface). This is a desired feature for a service-style API that is not bound to a particular process or system and is available as a remote procedure call.

The API itself is largely abstract in that it specifies an interface and controls the behavior of the objects specified in that interface. The software that provides the functionality described by an API is said to be an implementation of the API. An API is typically defined in terms of the programming language used to build an application. The related term, ABI (Application Binary Interface), is a lower level definition concerning details at the Assembly language level. For example, the Linux Standard Base is an ABI, while POSIX is an API.^[4]

The API acronym may sometimes be used as a reference, not only to the full interface, but also to a single function or even a set of multiple APIs provided by an organization. Thus the scope is usually determined by the person or document that communicates the information.

Implementations

The POSIX standard defines an API that allows a wide range of common computing functions to be written such that they may operate on many different systems (Mac OS X and various BSDs implement this interface); however, making use of this requires re-compilation for each platform. A compatible API, on the other hand, allows compiled object code to function without any changes, on any system implementing that API. This is advantageous to both software providers (where they may distribute existing software on new systems without producing/distributing upgrades) and users (where they may install older software on their new systems without purchasing upgrades), although this generally requires various software libraries implementing the necessary APIs too.

Microsoft has shown significant commitment to a backward compatible API, particularly within their Win32 library, such that older applications may run on newer versions of Windows. Apple Inc. has shown less propensity to this concern, breaking compatibility or implementing API in a slower "emulation mode"; this allows greater freedom in development at the cost of making older software obsolete.

Among Unix-like operating systems, there are many related but incompatible operating systems running on a common hardware platform (particularly Intel 80386-compatible systems). There have been several attempts to standardise the API such that software vendors may distribute one binary application for all these systems; however to date, none of these have met with much success. The Linux Standard Base is attempting to do this for the Linux platform, while many of the BSD Unices (OpenBSD/NetBSD/FreeBSD) implement various levels of API compatibility for both backward compatibility (allowing applications written for older versions to run on newer distributions of the system) and cross-platform compatibility (allowing the execution of foreign code without recompilation).

Release policies

Common API publishing policies include:

1. Companies do not release API information to anybody outside of the company.
2. Companies protect information on their APIs from the general public. For example, Sony used to make its official PlayStation 2 API available only to licensed PlayStation developers. This enabled Sony to control who wrote PlayStation 2 games. Such control can have quality control benefits and potential license revenue.
3. Companies make their APIs freely available. For example, Microsoft makes the Microsoft Windows API public and Apple releases its APIs Carbon and Cocoa so that software can be written for their platform.

API examples

API management

APIs are changing the way in which web-based companies interact on Internet and have become a complete distribution channel for web services and a potential source of revenues. However, to exploit the full potential of APIs, companies need to build a management infrastructure. This generally includes the following features:

• Key management and customer sign-up: Automated issue tracking, refresh and control of API access keys.
• Limit management and enforcement.
• Usage plan management: Creation, modification and management of standard usage plans, each with different features sets, limits and/or pricing rules.
• Per customer limit and usage policy adaptation.
• Developer community tools: Growing visibility and API usage through online management of documentation and developer forums/discussions.
• Monitoring and analytics: Tracking information on a per user basis for hit patterns,volume and method usage.
• User messaging, ticket tracking and support tools: Interactive tools to deal with developer support queries.
• Billing and payments.
• Traffic proxies and caching: Traffic filtering and management components to improve service performance.

There are some companies who offer these management tools for those web services providers who don't have enough resources to build them or want to stay focused on their core service

Language bindings and interface generators

APIs that are intended to be used by more than one high-level programming language often provide, or are augmented with, facilities to automatically map the API to features (syntactic or semantic) that are more natural in those languages. This is known as language binding, and is itself an API. The aim is to encapsulate most of the required functionality of the API, leaving a "thin" layer appropriate to each language.

Below are listed some interface generator tools which bind languages to APIs at compile time.

• SWIG generates interfaces from many languages for many languages (Typically Compiled->Scripted)
• F2PY: Fortran to Python interface generator.
• XPCOM (Cross Platform Component Object Model) is a cross platform component model from Mozilla.

See also

• Application Binary Interface (ABI)
• Document Object Model (DOM)
• Mashup (web application hybrid)
• Open Service Interface Definitions (OSID)
• Plugin
• Software Development Kit (SDK)
• Web service
• List of 3D graphics APIs
• API Writers

References

1. ^ "Application Program Interface". Free On-line Dictionary of Computing. 1995-02-15. http://foldoc.org/Application+Program+Interface. Retrieved on 2009-06-28. 
2. ^ "Definition of: API". PC Magazine. 1996. http://www.pcmag.com/encyclopedia_term/0,2542,t=application+programming+interface&i=37856,00.asp. Retrieved on 2009-06-28. 
3. ^ Orenstein, David (2000-01-10). "QuickStudy: Application Programming Interface (API)". Computerworld. http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=43487. Retrieved on 2009-06-04. 
4. ^ Stoughton, Nick (April 2005). "Update on Standards" (PDF). USENIX. https://db.usenix.org/publications/login/2005-04/openpdfs/standards2004.pdf. Retrieved on 2009-06-04. 

External links

• Practical API Design book and collaboration site
• How to design a good API and why it matters-PDF
• The trends and the role of API-driven mashup building tools in the enterprise computing
• Service-Oriented Architecture (SOA): The Road to Enterprise Application Integration (EAI)
• Organized list of API references with fast as-you-type search
• ISO/IEC JTC 1 Directives, 5th Edition Version 3.0, Annex J: Guidelines for API standardization
• API functions tutorial for game making
• API Management