What Is an API?

An API is a defined contract between two pieces of software that specifies how they can talk to each other. Think of it as a menu at a restaurant: the kitchen (the service) can do many things internally, but you as the customer (the caller) only interact through what's on the menu. This keeps the internal complexity hidden and gives both sides a stable agreement to rely on.

The key insight is that an API is about abstraction and boundaries. The caller doesn't need to know how something works, only what to ask for and what to expect back.

The Core Components of an API

Every API, regardless of style, involves a few fundamental pieces:

An interface definition: The set of operations that are available, including what inputs they accept and what outputs they return. This is the "contract".
A request: The caller invokes an operation, providing any required parameters.
A response: The service processes the request and sends a result back, which could be data, a confirmation, or an error.
A transport layer: The mechanism by which the request and response physically travel. This might be a function call in memory, a network socket, or an HTTP connection over the internet.

A Concrete Example

Let's walk through a real scenario. Suppose a weather app on your phone needs to display the current temperature. The app itself has no idea how to measure weather. Instead, it calls a weather data API:

The app sends an HTTP GET request to https://api.weather.com/current?city=London.
The weather service receives the request, queries its databases and sensors, and assembles a result.
It sends back a structured response, often in JSON format, like: { "city": "London", "temp_c": 14, "condition": "Cloudy" }.
The app reads that data and renders it on screen.

The app never needed to know how the weather service collects data. It only needed to know the API contract: the URL structure, the expected parameters, and the response format.

How APIs Enable Communication Between Components

APIs solve a fundamental problem: how do two separate systems, possibly written in different languages, running on different machines, coordinate reliably? They do this through several mechanisms:

Standardized formats: Both sides agree on how data is encoded. JSON and XML are common choices for web APIs because they are language-agnostic and human-readable.
Protocols: Rules about how messages are structured and exchanged. HTTP/HTTPS is the dominant protocol for web APIs. Others like gRPC use binary protocols for higher performance.
Versioning: APIs can evolve over time. By versioning endpoints (e.g., /v1/users vs /v2/users), providers can introduce changes without breaking existing callers.
Authentication: APIs typically include a security layer, such as API keys or OAuth tokens, so that only authorized callers can make requests.

Common API Styles Worth Knowing

The term "API" is broad. Here are the most common patterns you will encounter:

REST (Representational State Transfer): The most widely used style for web services. It uses standard HTTP verbs (GET, POST, PUT, DELETE) and treats everything as a resource with a URL. Stateless by design, meaning each request contains all the information needed to process it.
GraphQL: A query language for APIs where the client specifies exactly what data it needs. Useful when different clients (mobile vs. desktop) need different shapes of data from the same service.
gRPC: A high-performance framework that uses Protocol Buffers (binary format) instead of JSON. Common in internal microservice communication where speed matters.
Library/SDK APIs: Not all APIs are over a network. When you call a function from an imported library in your code, that is also an API. The principle is the same: a defined interface hiding internal implementation.

Why This Design Pattern Matters

The deeper reason APIs are so valuable comes down to three properties:

Decoupling: The caller and the service can evolve independently. The weather service can upgrade its internal infrastructure without the app needing to change, as long as the API contract stays stable.
Reusability: One API can serve many different callers. A payment API like Stripe serves thousands of applications without each having to build their own payment infrastructure.
Composability: Complex systems are built by wiring together smaller services through their APIs. Modern applications are often described as being "API-first" precisely because this composition is central to how they are designed.

Likely Follow-Up Directions

If this question comes up in an interview, be ready to go deeper on a few angles:

The difference between REST and GraphQL and when to choose one over the other.
How to design a good API (clear naming, idempotent operations, meaningful error codes).
What happens when an API call fails (timeouts, retries, circuit breakers).
How rate limiting and authentication protect APIs from abuse.

Understanding APIs at this level sets the foundation for nearly everything in modern software development, from microservices architecture to third-party integrations to building your own public-facing products.

1900. API Basics Overview

Similar Questions