Application programming interface
In computer programming, an Application Programming Interface (API) is a set of routine definitions, protocols, and tools for building software and applications. A good API makes it easier to develop a program by providing all the building blocks, which are then put together by the programmer. An API may be for a web-based system, operating system, database system, computer hardware, or software library. An API specification can take many forms, but often include specifications for routines, data structures, object classes, variables, or remote calls. POSIX, Microsoft Windows API, the C++ Standard Template Library, and Java APIs are examples of different forms of APIs. Documentation for the API is usually provided to facilitate usage. The status of APIs in intellectual property law is controversial.
- 1 Purpose
- 2 Uses
- 3 Design
- 4 Release policies
- 5 Documentation
- 6 Copyright controversy
- 7 Examples
- 8 Language bindings and interface generators
- 9 See also
- 10 Notes
- 11 References
- 12 Further reading
Just as a graphical user interface makes it easier for people to use programs, application programming interfaces make it easier for developers to use certain technologies in building applications. By abstracting the underlying implementation and only exposing objects or actions the developer needs, an API reduces the cognitive load on a programmer. While a graphical interface for an email client might provide a user with a button that performs all the steps for fetching and highlighting new emails, an API for file input/output might give the developer a function that copies a file from one location to another without requiring that the developer understand the file system operations occurring behind the scenes.
Libraries and frameworks
An API is usually related to a software library: the API describes and prescribes the expected behavior while the library is an actual implementation of this set of rules. A single API can have multiple implementations (or none, being abstract) in the form of different libraries that share the same programming interface. The separation of the API from its implementation can allow programs written in one language to use a library written in another. For example, because Scala and Java compile to compatible bytecode, Scala developers can take advantage of any Java API.
API use can vary depending on the type of programming language involved. An API for a procedural language such as Lua could primarily consist of basic routines to execute code, manipulate data, or handle errors, while an API for an object oriented language such as Java would provide a specification of classes and their class methods.
An API can also be related to a software framework: a framework can be based on several libraries implementing several APIs, but unlike the normal use of an API, the access to the behavior built into the framework is mediated by extending its content with new classes plugged into the framework itself. Moreover, the overall program flow of control can be out of the control of the caller, and in the hands of the framework via inversion of control or a similar mechanism.
The POSIX standard defines an API that allows writing a wide range of common computing functions in a way such that they can operate on many different systems (Mac OS X, and various Berkeley Software Distributions (BSDs) implement this interface).However, using this requires re-compiling for each platform. A compatible API, on the other hand, allows compiled object code to function with no changes to the system that implements that API. This is beneficial to both software providers (where they may distribute existing software on new systems without producing and →distributing upgrades) and users (where they may install older software on their new systems without purchasing upgrades), although this generally requires that various software libraries implement the necessary APIs as well.
Microsoft has shown a strong commitment to a backward compatible API, particularly within their Windows API (Win32) library, such that older applications may run on newer versions of Windows using an executable-specific setting called "Compatibility Mode".
An API differs from an application binary interface (ABI) in that an API is source code-based while an ABI is a binary interface. For instance POSIX is an API, while the Linux Standard Base provides an ABI.
Remote APIs allow developers to manipulate remote resources through protocols, specific standards for communication that allow different technologies to work together, regardless of language or platform. For example, the Java Database Connectivity API allows developers to query many different types of databases with the same set of functions, while the Java remote method invocation API uses the Java Remote Method Protocol to allow invocation of functions that operate remotely, but appear local to the developer. Therefore, remote APIs are useful in maintaining the object abstraction in object-oriented programming; a method call, executed locally on a proxy object, invokes the corresponding method on the remote object, using the remoting protocol, and acquires the result to be used locally as return value. A modification on the proxy object will also result in a corresponding modification on the remote object.
Several principles are commonly used to govern the process of designing APIs. Parnas proposed the concept of information hiding in 1972. The principle of information hiding is that one may divide software into modules, each of which has a specified interface. The interfaces hide the implementation details of the modules so that users of modules need not understand the complexities inside the modules. These interfaces are APIs, and as a result, APIs should expose only those module details that clients must know to use modules effectively. Software architecture is dedicated to creating and maintaining high-level software structures—which typically includes modules. APIs reflect interfaces between modules. Thus, a system architecture is inextricably related to the APIs that express that architecture. However, many decisions involved in creating APIs are not architectural, such as naming conventions and many details on how interfaces are structured.
These details of how interfaces are structured, as well as the software architecture, have significant impacts on software quality. For example, Cataldo et al. found that bugginess is correlated with logical and data dependencies in software. This implies that to reduce bug rates, software developers should carefully consider API dependencies.
Conway's Law states that the structure of a system inevitably reflects the structure of the organization that created it. This suggests that to understand how APIs are designed in the real world, one must also understand the structures of software engineering organizations. Likewise, an API group should structure itself according to what the API needs. In a study of 775 Microsoft software engineers, Begel et al. found that in addition to coordinating regarding API design, software engineers even more commonly coordinate regarding schedules and features. This reinforces the view that software organizations collaborate extensively and that organizational structure is important.
Several authors have created recommendations for how to design APIs, such as Joshua Bloch, Kin Lane, and Michi Henning. Since one of the principles of API design is that an API should be consistent with other APIs already in use in the system, the details of API design are somewhat language- and system-dependent.
APIs are one of the most common ways technology companies integrate with each other. Those that provide and use APIs are considered as being members of a business ecosystem.
The main policies for releasing an API are:
- Protecting information on 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. This gives companies quality control privileges and can provide them with potential licensing revenue streams.
- Making 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 platforms.
A mix of the two behaviors can be used as well.
Public API implications
An API can be developed for a restricted group of users, or it can be released to the public.
An important factor when an API becomes public is its interface stability. Changes by a developer to a part of it—for example adding new parameters to a function call—could break compatibility with clients that depend on that API.
When parts of a publicly presented API are subject to change and thus not stable, such parts of a particular API should be explicitly documented as unstable. For example, in the Google Guava library the parts that are considered unstable, and that might change in a near future, are marked with the Java annotation
A public API can sometimes declare parts of itself as deprecated. This usually means that such part of an API should be considered candidates for being removed, or modified in a backward incompatible way.
When adopting a third-party public API, developers should consider the deprecation policy used by the producer of that API; if a developer publicly releases a solution based on an API that becomes deprecated, he/she might be unable to guarantee the provided service.
API documentation describes what services an API offers and how to use those services, aiming to cover everything a client would need to know to use the API. Documentation is crucial for the development and maintenance of applications that use the API. API documentation is traditionally found in documentation files, but can also be found in social media such as blogs, forums, and Q&A websites. Traditional documentation files are often presented via a documentation system, such as Javadoc or Pydoc, that has a consistent appearance and structure. However, the types of content included in the documentation differs from API to API. To facilitate understanding, API documentation can include description of classes and methods in the API as well as "typical usage scenarios, code snippets, design rationales, performance discussions, and contracts", but implementation details of the API services themselves are usually omitted. Restrictions and limitations on how the API can be used are also covered by the documentation. For example, documentation for an API function could note that its parameters cannot be null, or that the function itself is not thread safe. Because API documentation is so comprehensive, it can be difficult for the writers to keep the documentation updated and for the users to read it carefully, potentially resulting in bugs.
API documentation can be enriched with metadata information like Java annotations. This metadata can be used by the compiler, tools, and by the run-time environment to implement custom behaviors or custom handling.
In 2010, Oracle Corporation sued Google for having distributed a new implementation of Java embedded in the Android operating system. Google had not acquired any permission to reproduce the Java API, although a similar permission had been given to the OpenJDK project. Judge William Alsup ruled in the Oracle v. Google case that APIs cannot be copyrighted in the U.S, and that a victory for Oracle would have widely expanded copyright protection and allowed the copyrighting of simple software commands:
To accept Oracle's claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing their own different versions to carry out all or part of the same commands.
In 2016, following a two week trial, a jury determined that Google's reimplementation of the Java API constituted fair use, but Oracle vowed to appeal the decision.
- ASPI for SCSI device interfacing
- Cocoa and Carbon for the Macintosh
- DirectX for Microsoft Windows
- Java APIs
- ODBC for Microsoft Windows
- OpenAL cross-platform sound API
- OpenCL cross-platform API for general-purpose computing for CPUs & GPUs
- OpenGL cross-platform graphics API
- OpenMP API that supports multi-platform shared memory multiprocessing programming in C, C++ and Fortran on many architectures, including Unix and Microsoft Windows platforms.
- Server Application Programming Interface (SAPI)
- Simple DirectMedia Layer (SDL)
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 that bind languages to APIs at compile time:
- SWIG – an open-source interfaces bindings generator supporting numerous programming languages
- F2PY – a Fortran to Python interface generator
- API testing
- API writer
- Calling convention
- Comparison of application virtual machines
- Common Object Request Broker Architecture CORBA
- Document Object Model DOM
- Double-chance function
- Foreign function interface
- Interface (computing)
- Interface control document
- List of 3D graphics APIs
- Name mangling
- Open API
- Open Service Interface Definitions
- Platform-enabled website
- RAML (software)
- Software Development Kit
- Web API
- Clarke, Steven (2004). "Measuring API Usability". Dr. Dobb's. Retrieved 29 July 2016.
- Odersky, Martin; Spoon, Lex; Venners, Bill (10 December 2008). "Combining Scala and Java". www.artima.com. Retrieved 29 July 2016.
- de Figueiredo, Luiz Henrique; Ierusalimschy, Roberto; Filho, Waldemar Celes. "The design and implementation of a language for extending applications" (PDF). TeCGraf Grupo de Tecnologia em Computacao Grafica. Retrieved 29 July 2016.
- Sintes, Tony. "Just what is the Java API anyway?". JavaWorld. Retrieved 29 July 2016.
- Fowler, Martin. "Inversion Of Control".
- Fayad, Mohamed. "Object-Oriented Application Frameworks".
- Microsogt (October 2001). "Support for Windows XP". Microsoft. p. 4.
- "LSB Introduction". Linux Foundation. 21 June 2012. Retrieved 2015-03-27.
- Stoughton, Nick (April 2005). "Update on Standards" (PDF). USENIX. Retrieved 2009-06-04.
- Bierhoff, Kevin (23 April 2009). "API Protocol Compliance in Object-Oriented Software" (PDF). CMU Institute for Software Research. Retrieved 29 July 2016.
- Wilson, M. Jeff. "Get smart with proxies and RMI". JavaWorld. Retrieved 29 July 2016.
- Henning, Michi; Vinoski, Steve (1999). "Advanced CORBA Programming with C++". Addison-Wesley. ISBN 978-0201379273. Retrieved 16 June 2015.
- Benslimane, Djamal; Schahram Dustdar; Amit Sheth (2008). "Services Mashups: The New Generation of Web Applications". IEEE Internet Computing, vol. 12, no. 5. Institute of Electrical and Electronics Engineers. pp. 13–15.
- Niccolai, James (2008-04-23), "So What Is an Enterprise Mashup, Anyway?", PC World
- Parr, Ben. "The Evolution of the Social Media API". Mashable. Retrieved 26 July 2016.
- Cataldo, M.; Mockus, A.; Roberts, J. A.; Herbsleb, J. D. (2009). "Software Dependencies, Work Dependencies, and Their Impact on Failures". IEEE Transactions on Software Engineering 99: 864–878. doi:10.1109/tse.2009.42.
- Begel, Andrew; Nagappan, Nachiappan; Poile, Christopher; Layman, Lucas. "Coordination in Large-Scale Software Teams". Proceedings of the 2009 ICSE Workshop on Cooperative and Human Aspects on Software Engineering: 1–9.
- Bloch, Josh. "How to design a good API and why it matters" (PDF).
- Lane, Kin (2016-03-14). "The Industry Guide to API Design" (PDF). Kin Lane via 3scale. Retrieved 2016-03-14.
- Henning, Michi. "API: Design Matters".
- de Ternay, Guerric (Oct 10, 2015). "Business Ecosystem: Creating an Economic Moat". BoostCompanies. Retrieved 2016-02-01.
- "guava-libraries - Guava: Google Core Libraries for Java 1.6+ - Google Project Hosting". Code.google.com. 2014-02-04. Retrieved 2014-02-11.
- Dekel, Uri; Herbsleb, James D. (May 2009). "Improving API Documentation Usability with Knowledge Pushing". Institute for Software Research, School of Computer Science (Carnegie Mellon University). Retrieved 22 July 2016.
- Parnin, Chris; Treude, Cristoph (May 2011). "Measuring API Documentation on the Web" (PDF). Web2SE. Retrieved 22 July 2016.
- Maalej, Waleed; Robillard, Martin P. (April 2012). "Patterns of Knowledge in API Reference Documentation" (PDF). IEEE TRANSACTIONS ON SOFTWARE ENGINEERING. Retrieved 22 July 2016.
- Monperrus, Martin; Eichberg, Michael; Tekes, Elif; Mezini, Mira (3 December 2011). "What should developers be aware of? An empirical study on the directives of API documentation" (PDF). Empirical Software Engineering 17 (6): 703–737. doi:10.1007/s10664-011-9186-4. Retrieved 22 July 2016.
- Shi, Lin; Zhong, Hao; Xie, Tao; Li, Mingshu (2011). "An Empirical Study on Evolution of API Documentation" (PDF). International Conference on Fundamental Approaches to Software Engineering (Springer Berlin Heidelberg). Retrieved 22 July 2016.
- "Annotations". Sun Microsystems. Retrieved 2011-09-30..
- "Oracle and the End of Programming As We Know It". DrDobbs. 2012-05-01. Retrieved 2012-05-09.
- "APIs Can't be Copyrighted Says Judge in Oracle Case". TGDaily. 2012-06-01. Retrieved 2012-12-06.
- "Oracle America, Inc. vs. Google Inc." (PDF). Wired. 2012-05-31. Retrieved 2013-09-22.
- Rosenblatt, Seth (May 9, 2014). "Court sides with Oracle over Android in Java patent appeal". CNET. Retrieved 2014-05-10.
- "Google beats Oracle—Android makes "fair use" of Java APIs". Ars Technica. Retrieved 2016-07-28.
- "F2PY.org". F2PY.org. Retrieved 2011-12-18.
- Taina Bucher (2013). "Objects of Intense Feeling: The Case of the Twitter API". Computational Culture (3). ISSN 2047-2390. argues that "APIs are far from neutral tools" and form a key part of contemporary programming, understood as a fundamental part of culture.