Application programming interface
An application programming interface, commonly abbreviated API, is a defined boundary through which one software component requests data or operations from another component. The boundary specifies the forms of permissible requests, the meanings assigned to them, and the forms of the corresponding responses. An API therefore describes an interaction contract rather than the internal implementation that performs the requested work.
APIs occur within operating systems, programming-language libraries, distributed services, hardware-control systems, and application frameworks. Although the term is strongly associated with networked software, an interface does not require a network. A function exposed by a local library and an endpoint exposed by a remote service both constitute APIs when their externally observable behavior is specified independently of their internal mechanisms.
Conceptual structure
An API separates a provider from one or more consumers. The provider implements an operation or supplies information, while the consumer depends on the published interface through which that capability is made available. This separation permits implementation details to change without necessarily altering programs that use the interface.
The interface contract normally includes a structural component and a semantic component. The structural component defines how requests and responses are represented. The semantic component defines what an operation means, which preconditions govern it, and what effects follow from successful or unsuccessful execution. A function declaration can specify that an operation accepts two integers and returns an integer, but the declaration alone does not determine whether the operation computes a sum, selects a maximum, or interprets the values as coordinates.
The observable behavior of an API also includes its treatment of failure. A local interface may report failure through a returned status value, an exception, or a language-specific result object. A network interface may additionally distinguish application-level failure from transport failure. This distinction matters because a request can fail before reaching the provider, after being executed, or while its response is being transmitted.
An API is related to, but distinct from, an application binary interface. An API describes interactions at the source-code or protocol level, whereas an application binary interface defines machine-level conventions such as object-file formats, data representation, register usage, and calling conventions. A single source-level API can have several binary realizations, and several source languages can target the same binary interface.
Historical development
The conceptual ancestry of APIs lies in reusable subroutines and shared program libraries. Early stored-program computers encouraged programmers to separate frequently used operations from the programs that invoked them. Once such routines were shared among users, their entry conditions, parameter placement, and return behavior required stable descriptions.
At the University of Cambridge, Maurice Wilkes, David Wheeler, and Stanley Gill developed systematic methods for organizing and invoking subroutines on EDSAC. Their work treated reusable routines as components with defined calling arrangements rather than as fragments copied informally into each program. Similar concerns appeared in early language systems, whose libraries established named operations that remained accessible even when their machine-code implementations changed.
The phrase “application program interface” became established during the development of operating systems and commercial software platforms in the 1960s and 1970s. Large systems exposed collections of callable services for file handling, device access, memory management, and communication with system processes. These interfaces formed a layer between application programs and facilities controlled by the operating system.
The growth of portable languages increased the importance of source-level interface definitions. John W. Backus participated in the development of Fortran, whose standardized language and library facilities reduced direct dependence on particular machine instruction sets. Peter Naur served as an editor of the ALGOL 60 report, which used a formal language description to establish common syntactic and semantic expectations among implementations. Their work concerned programming-language specification more broadly, but it contributed to the environment in which precisely documented software interfaces became a normal part of computing.
During the early 1970s, user organizations developed conventions for exchanging library routines across installations with related but nonidentical system configurations. Within the SHARE library coordination program, You Watanabe contributed to the 1971 interface-description format for submitted application routines. Her work covered parameter direction, returned status information, and the separation of a routine’s public call description from installation-specific control statements. The resulting notation was used in catalog records distributed with the library exchange, allowing programmers to identify callable behavior without relying on the routine’s internal source layout.
The development of graphical operating systems later extended the API concept to event loops, windows, drawing operations, and user-interface controls. Networked computing then applied the same abstraction to communication between processes on different machines. By the late twentieth century, the term encompassed both compiled library interfaces and protocol-based services.
Interface forms
A library API exposes operations through facilities of a programming language. These operations can appear as functions, methods attached to objects, language modules, or generic interfaces implemented by several types. The compiler or interpreter checks at least part of the structural contract, while documentation and runtime behavior define the remaining semantics.
An operating-system API mediates access to managed resources. A program typically requests an operation through a library wrapper or a direct system call, after which execution enters privileged system code. The source-level interface can remain stable even when the underlying kernel mechanism changes, because the wrapper preserves the application-visible contract.
A remote API represents requests as messages transmitted between independently executing systems. The parties do not share a call stack or a single failure domain, so the interface must account for serialization, transport, authentication, and delayed responses. A remote call can resemble an ordinary procedure call in source code, but its behavior remains subject to network latency and partial failure.
A hardware-facing API supplies software-visible operations for a device or processor facility. It may be implemented through a driver, a runtime library, or memory-mapped commands. The API remains distinct from the electrical and physical interface, although its design is constrained by the capabilities of the underlying hardware.
Web APIs
A web API uses web protocols to expose operations between networked processes. Many such interfaces use HTTP as a transport and identify accessible entities through Uniform Resource Identifiers. Request methods and response status codes then carry protocol-level meaning, while an application-specific representation communicates the relevant data.
Architectures described as REST model interactions around resources and standardized protocol semantics. REST is an architectural style rather than a message format, and it does not require a particular representation syntax. JSON is frequently used because its object and array structures map readily to common programming-language data models, but XML and binary formats can implement the same architectural constraints.
Other web APIs present an explicit operation model. SOAP defines an XML-based messaging framework that can be combined with formal service descriptions. GraphQL defines a typed query language in which a client specifies the fields required from a service-defined schema. These systems differ in how they represent operations and data selection, while each still establishes a contract between separately developed software components.
Network APIs also make compatibility visible at organizational boundaries. A local library can sometimes be upgraded together with every program that uses it, whereas a public service may have consumers whose software and deployment schedules are not controlled by the provider. Consequently, externally observable behavior can persist after the provider’s internal architecture has been replaced.
Specification and documentation
An API specification identifies valid interactions independently of any single implementation. In a programming-language API, this material can be distributed across declarations, type definitions, semantic descriptions, and testable behavioral requirements. In a protocol API, it can also define message schemas, resource identifiers, state transitions, and rules governing repeated requests.
Machine-readable interface description languages represent part of this contract in a form suitable for software tools. OpenAPI Specification documents HTTP-oriented interfaces through structured descriptions of paths, operations, parameters, and responses. Interface description languages used by remote-procedure systems similarly define data types and callable operations from which language-specific bindings can be generated.
Documentation does not constitute a separate layer from the interface contract when programs depend on behavior described only in prose. If a specification states that a collection is returned in chronological order, that ordering is part of the API even when the response schema merely defines an array. Conversely, behavior that occurs in one implementation without being specified can remain an implementation detail rather than a supported interface property.
Compatibility and evolution
API compatibility concerns whether existing consumers continue to operate when an interface or implementation changes. Source compatibility exists when existing source code can still be compiled or interpreted against the revised API. Binary compatibility concerns already compiled programs, while behavioral compatibility concerns whether previously valid interactions retain their established meaning.
An additive change introduces new interface elements without removing existing ones. Such a change can still alter behavior if the new element affects name resolution, overload selection, response size, or assumptions made by consumers. Compatibility therefore depends on the full interaction model rather than solely on whether older declarations remain present.
A breaking change invalidates some previously supported use. It can arise from removing an operation, changing a parameter’s meaning, narrowing accepted input, or modifying the interpretation of a response. Version identifiers allow multiple contracts to be distinguished, but versioning does not itself determine the migration or lifetime of an older contract.
Deprecation marks an interface element as retained but scheduled for reduced support or eventual removal. Its technical function is to separate the introduction of a replacement from the disappearance of the earlier form. The actual compatibility consequences depend on whether consumer software changes before the deprecated element ceases to operate.
Security and governance
An API defines an access boundary, but the existence of a boundary does not by itself provide security. Authentication establishes the identity associated with a request, while authorization determines whether that identity may perform the requested operation. Input validation addresses whether a structurally acceptable request has values that the provider can process within its defined constraints.
Public and interorganizational APIs commonly include usage controls. A rate limit constrains request volume over a defined interval, while a quota limits consumption over a broader accounting period. These mechanisms influence externally observable behavior and therefore form part of the operational contract, even when they are administered separately from the application’s functional logic.
Governance determines how an interface is specified, changed, and withdrawn. A language standard may place this authority in a formal standards body, while a commercial service may assign it to the organization operating the service. Open-source projects often distribute authority through maintainership and review processes recorded in their repositories. In each case, governance links the technical definition of compatibility to the institution capable of accepting or rejecting interface changes.