What Is an API?

A delivery application shows that a package will arrive before six in the evening.

In this example, the application gets delivery data from the carrier's server. It sends a tracking number and receives a structured response. It then displays those values on the screen.

The agreement that made that exchange possible is an API.

An API, short for application programming interface, is a published agreement that lets one program use another program's capability without knowing how that capability is built.

Published means the interface is available to its intended users; it does not have to be public on the internet. Interface means the set of operations and rules that callers use. Callers do not need to know the internal implementation.

1. The Two Sides of Every API

Every API has a provider and a consumer.

The provider is the team or service that publishes the API and operates the code behind it. The consumer, also called the caller or the client, is the program that uses it. In the delivery example, the carrier is the provider and the phone application is the consumer.

For a network API, the client and server are different programs. They may use different languages or belong to different teams or companies. The client can use the carrier's tracking service without having to build or operate it.

2. What One Call Contains

A call has two halves. The consumer sends a request, and the provider returns a response.

A request to read one shipment looks like this:

GET /shipments/shp_81M
Authorization: Bearer <credential>

The response carries the answer:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": "shp_81M",
  "tracking_number": "1Z-4471-9930",
  "status": "in_transit",
  "estimated_delivery_at": "<RFC 3339 UTC timestamp>"
}

Every part of that exchange has a name, and the rest of the course uses those names constantly.

An operation is an action a client can perform, such as reading a shipment. In an HTTP API, the method describes the type of action, and the path identifies the resource. Headers provide information about the request or response, such as credentials or the format of the data. The body, also called the payload, contains the data sent in the message. The status code is a number that describes the result of the request.

The contract includes these message formats and the rules for using them. For example, it says which fields are always present, what happens when a shipment does not exist, and whether repeating a request is safe. It also defines the behavior that future versions must continue to support.

3. The Vocabulary in One Place

These terms recur in every chapter, so it is worth reading them once as a set.

Two of them are easy to confuse. An endpoint is a location the caller can address. An operation is one thing the caller can do at that location. Reading a shipment and deleting a shipment can share one address while remaining two operations with different inputs, different permissions, and different failures.

4. Why Programs Publish an API at All

An API is useful when another program needs to use a capability without building and operating it itself. The following benefits explain why.

Reuse without rebuilding. The phone application can request tracking information without operating a delivery network.

The implementation stays replaceable. The carrier can change its database, split a service, or add a cache. Clients can continue sending the same requests if the server still follows the API contract.

Access stays controlled. The provider decides who may call the API, what each client may access, and how often it may send requests. The API can enforce these rules without giving clients direct access to storage.

Teams move independently. An API lets teams release internal changes on separate schedules, provided they continue to follow the shared contract.

Other people build things you did not plan. Developers may use a payment API in products its authors did not expect. This creates new uses for the service, but it also makes later changes harder to coordinate. Section 6 explains why.

5. The Kinds of API You Will Meet

The term API includes several kinds of interface. Clarify which kind the interview question refers to.

By where the code runs. A library API provides functions or types that other code can use, usually in the same process. An operating-system API lets a program request services such as opening a file or a network connection. A web API is accessed over a network. This course focuses mainly on web APIs.

By who is allowed to call. An API may serve internal teams, selected partners, or public developers. The audience affects access rules, documentation, and how changes are introduced.

By the style of the contract. A web API can be expressed in more than one way. REST addresses things by URL and acts on them through a small fixed set of methods. gRPC defines typed service methods in a schema and generates code for both sides. GraphQL publishes a typed graph and lets the caller select the fields it wants. Related mechanisms cover what a plain request cannot: webhooks, where the provider calls the consumer back, and streaming, where one connection carries a sequence of updates.

The course uses REST as its starting point, and Chapter 2 covers it in detail. Chapter 3 explains when other approaches are useful and what disadvantages they introduce.

6. Published Decisions Are Permanent Decisions

This is the central idea of the course, and it is the reason API design is a distinct skill rather than a naming exercise.

Imagine that you own an internal function:

loadCustomerProfile(customerId)

You decide getCustomerProfile is clearer. Tools find the call sites, you update them, and you deploy. You control both the function and its callers.

Now imagine your API publishes this response:

{
  "user_id": "usr_7241",
  "display_name": "Mina Patel"
}

Six months later you decide name is cleaner than display_name. If you rename it, existing applications still look for the old field. They may show a blank label, reject the response, or fail somewhere you cannot see. Some callers are partner integrations at other companies, some are scripts with no maintainer, some are old mobile applications nobody has updated. No tool finds those callers for you, and you cannot make them all deploy at the same time as you.

This small rename now requires a migration plan. The diagram shows one way to introduce it while supporting existing clients.