Application programming interface

An API defines a usable boundary between software components. One component, the client, makes a request or invokes an operation; another component, the server or library, performs work and returns a result according to the API contract.¹ The contract can cover names, parameters, return values, data types, authentication, error conditions, and compatibility rules. Because the implementation remains behind the boundary, an API lets developers replace or revise internal code while preserving the interface that dependent programs use.

APIs occur inside a single operating system, between libraries and applications, across a network, or between independent organizations. A file-system API and a web API differ in transport and representation, but both expose defined capabilities through agreed conventions. The interface is therefore not synonymous with a website, a graphical user interface, or a particular programming language.

APIs take several forms, distinguished chiefly by where communication occurs and how operations are represented. A language library may expose functions and classes directly; an operating-system API may mediate files, processes, devices, or permissions; and a remote API may exchange messages over a protocol such as HTTP.² Web APIs commonly identify resources with URLs and use methods, status codes, headers, and representations, while other designs use remote procedure calls, event streams, or query languages.

The visible interface can be textual, binary, or generated from a formal schema. Web IDL, for example, provides a language for describing interfaces used by web-platform specifications.³ An API may be synchronous or asynchronous, stateful or stateless, public or private, and local or distributed. These are design properties rather than competing definitions.

A reliable API depends on an explicit contract, predictable behavior, and disciplined change management. Documentation should state valid inputs, output schemas, failure modes, authentication requirements, rate limits, examples, and whether an operation is safe to repeat. For HTTP-based services, status codes and method semantics provide standardized signals that clients can interpret consistently.²

Formal descriptions help tools generate documentation, client libraries, test cases, and validation. The OpenAPI Specification is a widely used format for describing HTTP APIs and their operations.⁴ Compatibility policy is equally significant: additive changes are often less disruptive than removing fields or changing their meaning, but even an added requirement can break clients. Version identifiers, deprecation periods, changelogs, contract tests, and monitoring make evolution more manageable.

API boundaries also define security, economics, and organizational responsibility, not merely data exchange. An API can limit what a caller may do through authentication, authorization, quotas, and scope; OAuth 2.0, for instance, specifies an authorization framework in which a client can obtain limited access to protected resources.⁶ A service API may expose sensitive capability even when individual endpoints appear harmless, so threat modeling must consider combinations of operations.

Some important APIs are deliberately stable and unobtrusive. POSIX standardizes interfaces that allow application software to interact with Unix-like operating-system services across implementations.⁷ In distributed systems, an API also becomes a reliability boundary: timeouts, retries, idempotency, partial failure, and observability affect correctness. API gateways and service meshes may enforce policy around the interface, but they do not remove the need for a clear underlying contract.

API contract

The documented rules governing an interface's operations, data, errors, security, and compatibility.

Client

A program or component that invokes an API.

Endpoint

A network-accessible location and operation through which an API can be called.

Idempotency

A property in which repeating an operation has the same intended effect as performing it once.

Schema

A formal description of the structure and permitted values of data exchanged through an API.