API
In plain English
Plain definition
An API (Application Programming Interface) is a defined contract letting software components exchange requests and data; correctness depends on versioning, authentication scope and validated error handling.
Technical Definition
Formally, an API specifies the operations, inputs, outputs, error conditions and invocation mechanism through which one software component (a client) interacts with another (a service or library). APIs may be exposed over a network using protocols and styles such as REST over HTTP, GraphQL, gRPC, or as in-process function signatures within a language runtime or operating system. The API surface typically includes versioned endpoints or methods, a schema or type contract for requests and responses, an authentication and authorisation model, and documented error semantics. The API itself is the interface; the underlying implementation behind it can change without affecting consumers, provided the contract is preserved.
Operational Relevance
APIs are the primary integration surface for platform and operations work: automation scripts, monitoring agents, identity providers and CI/CD pipelines interact with target systems almost exclusively through their APIs rather than through direct manual configuration. Operationally material concerns include rate limiting, authentication token lifecycle, backward-compatible versioning, and consistent error responses. A change to an API’s contract, such as a renamed field or an altered authentication requirement, can silently break every downstream integration that depends on it, so contract stability and clear deprecation notice are treated as operational risk factors rather than purely development concerns.
Architecture Relationship
An API sits at a boundary within a larger architecture: it decouples consumers from producers so that internal implementation, storage or infrastructure can evolve independently on either side of the contract. In service-oriented and microservice architectures, APIs are the primary mechanism by which services communicate, and API gateways, service meshes and identity platforms are commonly layered around them to enforce authentication, throttling and observability. In cloud and SaaS platforms, the API is often the only supported way to configure or query the system, which makes API design, versioning discipline and access control central architectural decisions rather than peripheral implementation detail.
Example
A monitoring system calls a cloud provider’s REST API to retrieve the current status of a virtual machine. The request includes an authentication token and a resource identifier; the response is a structured document, typically JSON, describing the resource’s state. Neither the monitoring system nor the cloud provider needs to know how the other is implemented internally: they only need to honour the documented request and response contract.
Common Misunderstanding
A frequent misunderstanding is treating “API” as synonymous with “REST API” or with any specific transport protocol. API is a general concept describing an interface contract; REST, GraphQL, gRPC and SOAP are particular styles or protocols for implementing an API over a network, and many APIs are not network-based at all, such as a programming language’s standard library interface. Another common error is assuming an API’s behaviour is stable indefinitely; providers can deprecate or version endpoints, so version-sensitive claims about specific API behaviour require confirmation against current, dated documentation rather than assumed permanence.
Related Terms
- REST: an architectural style commonly used to implement web APIs.
- GraphQL: a query-language-based API style allowing clients to request specific data shapes.
- Endpoint: a specific addressable operation or resource exposed by an API.
- Authentication: the mechanism by which an API verifies the identity of a caller.
- Rate limiting: a control that restricts how frequently an API may be called by a given consumer.
Further Reading and Verification
Readers should confirm current endpoint behaviour, authentication requirements and versioning policy directly against the specific API provider’s own current documentation before relying on it operationally, since API contracts and supported versions change over time. Where an API underpins a production integration, validate contract assumptions in an isolated or non-production environment and confirm permissions and version compatibility before applying any configuration change that depends on it.