What Is an API?
By the end of this lesson
Explain what an API is, who consumes it, and why the contract matters more than the implementation.
An API is a way for one piece of software to ask another to do something.
A web API does this over HTTP. A mobile app needs a list of customers; it sends a request to your server; your server replies with the data. The app does not know or care whether you used a database, a spreadsheet or carrier pigeons.
That separation is the entire value. Because the caller only knows the contract — which addresses exist, what they accept, what they return — you are free to change everything behind it. Swap the database, rewrite the logic, split the service in two: as long as the contract holds, nothing breaks.
The reverse is also true, and it is the part people learn painfully. Once other software depends on your contract, changing it breaks them. That is why API design deserves thought before implementation.
Who is on the other end
The same API typically serves several consumers:
- A web front end in the browser
- A mobile application
- Internal admin tools
- Scheduled jobs and background processes
- Another team's service
- A customer's own integration
This is why business rules belong behind the API rather than in the front end. If the web app enforces that a discount cannot exceed twenty percent but the API does not, then the mobile app, the admin tool and anyone with a terminal can exceed it.
What a request and response look like
GET /api/employees?role=engineer&page=1 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer <token>- GET states the intent: retrieve something, change nothing.
- The path identifies what is wanted, and the query string refines it.
- Headers carry everything else — the format wanted, and who is asking.
{
"items": [
{ "id": 12, "name": "Asha", "role": "Engineer" },
{ "id": 19, "name": "Ravi", "role": "Engineer" }
],
"page": 1,
"pageSize": 20,
"totalCount": 2
}- The data is wrapped in an object rather than returned as a bare array. That leaves room to add paging information without breaking existing callers.
- Returning a bare array is a decision that is difficult to reverse later, which is a good early illustration of why contract design matters.
Summary
- An API lets software call software, and a web API does it over HTTP
- The contract is what callers depend on — change it and you break them
- Business rules must be enforced server-side, because clients can be bypassed
- Return objects rather than bare arrays so the response can grow without breaking callers
Practice
Attempt each one before opening the solution. Getting it wrong first is how the idea sticks.
Think about it
Think about it
An endpoint returns a bare JSON array of employees. Six months later you need to add paging. Why is that now a breaking change, and what would have avoided it?
Show solution
Existing callers parse the response as an array. Wrapping it in an object to add page information changes the shape, so every one of them breaks.
Returning an object from the start — even one with a single items property — leaves room to add fields later, because adding a property is additive while changing the top-level shape is not.
Knowledge check
Nothing is recorded and there is no score. The explanation appears either way.
Saved in this browser only.