API

API stands for Application Programming Interface. It is the set of rules and endpoints that allows two applications to communicate. When a mobile app fetches weather data, a website loads a map, or a payment form processes a card — each is an API call.

How API calls work over the network

From a networking perspective, an API call is an HTTP request — indistinguishable from loading a webpage except the response is structured data (usually JSON) rather than HTML. The request travels over TCP/IP, goes through DNS resolution, and is subject to the same latency and bandwidth constraints as any other internet traffic. A 50 ms connection means every API call takes at least 50 ms — this is why latency matters as much as bandwidth for API-heavy applications.

REST vs SOAP

REST (Representational State Transfer) is the dominant API style on the web. It uses standard HTTP methods on resource URLs and returns JSON. REST is stateless — each request contains all the information needed to process it, and the server keeps no session state between calls. SOAP (Simple Object Access Protocol) is an older XML-based protocol that wraps every request in a rigid envelope structure. SOAP is still found in banking, healthcare, and enterprise integrations that were built before REST became standard. For new development, REST (or GraphQL) is almost always the better choice: lighter payloads, simpler tooling, and broad client support.

REST API anatomy

A REST API request has several components:

• Base URL — the root address of the API, e.g. https://api.example.com/v2
• Endpoint path — the resource path appended to the base URL, e.g. /users/42/orders
• HTTP method — GET (read), POST (create), PUT/PATCH (update), DELETE (remove)
• Headers — metadata sent with the request, including Authorization, Content-Type: application/json, and Accept
• Body — JSON payload for POST/PUT requests containing the data to create or update
• JSON response — the server's structured reply, typically with an HTTP status code indicating success or failure

API authentication methods

APIs must verify that the caller is authorised to make a request. Three approaches are common:

• API key — a static secret string sent in a header (X-API-Key) or query parameter. Simple to implement but provides no user-level identity and must be kept secret. If leaked, the key must be rotated.
• OAuth 2.0 — a delegated authorisation framework where a user grants a third-party application limited access to their account without sharing their password. The application receives an access token (typically a short-lived JWT) after the user approves the scope. Used by Google, GitHub, and most major platforms.
• JWT (JSON Web Token) — a signed token that encodes claims (user ID, roles, expiry) in a compact format. The server issues a JWT on login; subsequent requests carry it in the Authorization: Bearer <token> header. The server validates the signature without a database lookup, making JWTs efficient for stateless APIs.

Rate limiting and HTTP 429

APIs throttle requests to prevent abuse and protect server capacity. When a client exceeds the allowed request rate, the API returns HTTP 429 Too Many Requests, often with a Retry-After header indicating how long to wait. Rate limits are commonly expressed as requests per minute or per hour per API key or per IP. Well-behaved API clients implement exponential backoff — waiting progressively longer between retries after a 429 response.

API types compared

Webhooks vs polling

Many APIs deliver updates in one of two ways. Polling means the client repeatedly calls an endpoint on a schedule — "any new orders?" — which wastes requests when there is nothing new. Webhooks invert this: the server sends an HTTP POST to a URL you register whenever an event occurs. A payment processor webhooks your server when a transaction completes rather than you polling every 10 seconds. Webhooks are more efficient but require your server to have a publicly reachable HTTPS endpoint. For real-time use cases, WebSocket connections maintain a persistent bidirectional channel, eliminating both polling overhead and webhook delivery latency.

API latency and networking

Every API call has a minimum latency floor set by the round-trip time between the client and server. Techniques that reduce per-call overhead include:

• Connection reuse / keep-alive — HTTP keep-alive reuses a TCP connection for multiple requests, avoiding the cost of a new TCP handshake per call (roughly one round trip saved).
• HTTP/2 multiplexing — HTTP/2 sends multiple requests simultaneously over a single TCP connection, eliminating the head-of-line blocking of HTTP/1.1 where each request must wait for the previous response.
• CDN and edge caching — API responses for GET requests that return the same data to many users (product listings, public data) can be cached at CDN edge nodes. This moves the response from a data center hundreds of milliseconds away to an edge server tens of milliseconds away.
• Edge computing — running API logic itself at the CDN edge (Cloudflare Workers, AWS Lambda@Edge) eliminates the origin round trip entirely for suitable workloads.

Common API error codes

Frequently Asked Questions

What is an API in simple terms?

A defined way for one piece of software to request services or data from another — like a waiter taking your order to the kitchen and bringing back the result. The two sides agree on the interface without sharing internal code.

What is a REST API?

The most common web API style. Uses HTTP methods (GET, POST, PUT, DELETE) on resource URLs and returns JSON. Most public APIs you encounter — weather, maps, payments — are REST APIs.

How does an API call affect my network traffic?

Each call is an HTTP request. Apps polling APIs frequently (every few seconds) generate background traffic. On metered mobile connections this adds measurable data consumption, especially if responses are large.