A programming interface (also application interface , accurate interface for programming of applications ), often only briefly API called (of English application programming interface , literally, application programming ') is a program part of a software system other programs provided for connection to the system available becomes. In contrast to a binary interface (ABI), a programming interface only defines the program connection on the source code level. The provision of such an interface usually includes detailed documentation of the interface functions with their parameters on paper or as an electronic document.
In addition to access to databases or hardware such as hard disk or graphics card , a programming interface can also enable or simplify the creation of components for the graphical user interface . For example, the Windows Application Programming Interface of the Windows operating system enables external companies to develop software for this operating system in the first place.
Nowadays, many online services also provide programming interfaces; these are then called web service . In a broader sense, the interface of each library (English library ) as a programming interface. This type of functional programming interface must be distinguished from the many other interfaces that are used in programming - for example the parameters that are agreed and transferred when subroutines are called.
Classification according to type classes
Programming interfaces can be divided into the following type classes:
- function-oriented (e.g. dynamic link library )
- file-oriented (e.g. device files under Unix )
- object-oriented (e.g. ActiveX DLLs)
- protocol-oriented (e.g. FTP )
Function-oriented programming interfaces
Function-oriented programming interfaces only know functions with or without a return value as a means of communication. The concept of handles is almost always used. You call a function and get a handle back. This handle can be used to call other functions until the handle has to be closed again.
File-oriented programming interfaces
File-oriented programming interfaces are beyond the normal file system calls
closeaddressed. If data is to be sent to an object, it is also
writewritten; if it is to be received, it is also
readread. Under UNIX, this principle is widespread for controlling device drivers.
Object-oriented programming interfaces
Object-oriented programming interfaces use interface pointers and are therefore significantly more flexible than the function-oriented programming interfaces. A type library is often provided .
Protocol-oriented programming interfaces
Protocol-oriented programming interfaces are independent of the operating system and hardware . However, the protocol must always be re-implemented. In order to minimize this effort, the protocol-oriented interface is encapsulated by a function- or interface-oriented interface. A distinction can also be made here between general (e.g. SOAP ) and application-specific (e.g. SMTP ) protocols.
Classification according to development stages
In the case of programming interfaces for application software , a distinction is also made according to development level . The starting point for this distinction is the observation that the operations of the programming interface often only develop over time. It is of great importance whether the operations available in earlier versions of the programming interface are still available in all subsequent versions and have the same meaning . With a stable interface, the application no longer needs to be changed. A distinction is made between evolving and stable programming interfaces ( API ). As refactoring the further development of a programming interface is known that no changes pulls in the user programs whenever possible.
Having a well-documented programming interface (API) can be a significant competitive advantage for a software or hardware product containing the software - as it enables other software companies or freelance programmers to create additional software for that system. With the offer of additional programs from third-party providers, the attractiveness of the original system, for example a computer operating system, a game console or a smartphone family, increases. The business policy with regard to this interface can thus decide on the commercial success of a software and possibly also the associated hardware. For example, some software providers charge considerable sums of money for the associated, necessary documentation, which represents a barrier to entry for interested programmers. It can also be provided that the API can only be accessed with a software development system that is expensive to acquire .
Another factor for success can be the long-term stability of the API mentioned above, because frequent changes also force the programmer of an additional application to change his software each time so that it continues to work. This can result in a considerable amount of work and thus costs, which makes the development less commercially attractive.
The development environment Xcode , with the API of the smartphone operating system Apple iOS indeed can be accessed is, as a free download, but only for Mac computers from Apple . In addition, developers have to sign a nondisclosure agreement and pay a membership fee, which is considered an obstacle - especially since Apple is facing strong competition in the market for smartphones and mobile apps due to the great success of the Android operating system .
The POSIX standard defined by the IEEE exists for the Unix operating system family . The pricing for documentation for this API is very high, and its publication is prohibited by copyright law. In recent times, there has therefore been a tendency towards the Open Group's single UNIX specification . These standards are open, freely available on the Internet and anyone can submit suggestions.
- Erich Gamma , Richard Helm , Ralph Johnson , John Vlissides : Design Patterns - Elements of Reusable Object-Oriented Software . Addison-Wesley, Reading MA et al. a. 1995, ISBN 0-201-63361-2 .
- Joshua Bloch: How to Design a Good API and Why it Matters . ( scribd.com [PDF; 580 kB ]).
- Danny Dig, R. Johnson: How do APIs evolve? A story of refactoring . In Journal of Software Maintenance and Evolution . Research and Practice . Wiley, Chichester, New York 2006. pp. 1-26.
- All Your Apps Are Belong to Apple: The iPhone Developer Program License Agreement . Electronic Frontier Foundation . March 9, 2010. Retrieved April 17, 2010.