EMZETT.API
In short: Application Programming Interface — a defined interface through which two programs communicate with each other, without knowing each other’s internal implementation.
In more detail: Defines which functions/endpoints are available, what data you have to send, and what you get back. On the web, usually implemented as an HTTP interface, often following the REST principle. A good API hides complexity behind a stable, documented surface.
In Depth
APIs at different levels
APIs exist at various levels: a library API (e.g. a function in a programming-language library) is called directly in code, with no network communication. A web API is addressed over the network — usually via an HTTP request to a URL, with structured responses in JSON or XML format. An operating-system API (system calls) lets programs communicate with the underlying operating system (open a file, request memory). All three share the same basic principle: a fixed, documented interface, behind which arbitrarily complex internal logic can hide.
curl -X GET https://api.example.com/v1/customers/42 \
-H "Authorization: Bearer <token>"
curl -X POST https://api.example.com/v1/orders \
-H "Content-Type: application/json" \
-d '{"product_id": 7, "quantity": 2}'Versioning
A central concept in API design is versioning (/v1/, /v2/): if the API changes fundamentally (e.g. a field is renamed or removed), existing users shouldn’t break immediately — which is why old versions often stay reachable in parallel for a while, while new clients already use the new version. Some APIs version via HTTP headers instead of the URL, but the basic principle (preserving backward compatibility) stays the same.
Documentation and contracts
A well-documented API (e.g. via an OpenAPI/Swagger specification, a standardised machine-readable format) describes every endpoint, every expected parameter, every possible error code and the exact response format, so other developers can use it without knowing the internal source code. From an OpenAPI specification, interactive documentation pages, client code (see SDK) and even test cases can also be generated automatically — the specification becomes the “contract” between the API provider and its users.
Authentication
Most public APIs require some form of authentication, usually via an API key (a secret token in the header) or OAuth (for access on behalf of a user, e.g. “sign in with your Google account”) — without this safeguard, anyone could make unlimited requests, causing both cost and abuse risks.
Rate limiting and error handling
Publicly accessible APIs usually limit how many requests a client is allowed to make in a time window (“rate limiting”) — without this limit, a single faulty or malicious client could overload the entire infrastructure. If the limit is exceeded, the API typically responds with HTTP status 429 (“Too Many Requests”) instead of simply ignoring the request, so the calling client can detect the error and react accordingly (e.g. with exponential backoff — wait briefly after the first error, double the wait time on repeated errors).
GraphQL as an alternative to REST
Besides classic REST APIs, GraphQL has become established as an alternative, where the client specifies in a single request exactly which fields it needs, instead of relying on predefined, often overloaded endpoints as with REST. This reduces both over- and under-fetching of data (too many or too few fields per response), but increases complexity on the server side, since the flexibility of queries has to be actively managed (e.g. against overly expensive, deeply nested queries).