What Is an API?
Table of Contents
Understanding APIs
An API is a way for two programs to talk to each other.
The full name is Application Programming Interface. In backend development you will work with APIs all the time, both consuming them and building them.
This chapter explains what that really means, in simple, concrete terms.
Interface: The Core Idea
You already know interfaces from daily life.
- A remote control is an interface to your TV.
- A restaurant menu is an interface to the kitchen.
- An ATM keypad and screen are an interface to the bank’s system.
In all of these:
- You do not see the internal wiring or code.
- You have a clear set of allowed actions and rules for using them.
- If you follow the rules, you get predictable results.
An API is the same idea, but for software.
- It defines what you can ask a program to do.
- It defines how you must ask.
- It defines what you get back.
You do not need to know how it does the work internally.
Key Idea:
An API is a contract that describes how to use a piece of software from the outside, without knowing its internal implementation.
Application, Programming, Interface
Let us break down the term:
| Word | Meaning in “API” |
|---|---|
| Application | Any program or service, for example a web server, payment system, database |
| Programming | Used by programs, not by humans directly |
| Interface | The defined way to interact, like buttons, functions, or endpoints |
An API is not a graphical user interface (GUI). You usually do not click it with a mouse. Instead, your code or another application interacts with it, often over HTTP, using requests and responses.
A Simple Real-World Analogy: Restaurant Menu
Imagine a restaurant:
- Kitchen = backend system
- Menu = API
- Waiter = transport protocol (often HTTP)
- You = client application
You:
- Read the menu (API documentation).
- Choose an item, for example
"Cheeseburger". - Tell the waiter your order (request).
- The kitchen prepares food (internal logic you do not see).
- The waiter brings back the dish (response).
You do not:
- Enter the kitchen.
- Decide how long to grill the meat.
- Choose which brand of cheese they use.
You simply use the interface they provide.
In software, your application:
- Reads the API docs.
- Sends a request to a URL, for example
/orders. - The backend service does some work.
- The backend sends back a response with data, for example JSON.
What Does an API Look Like?
There are many kinds of APIs, but in web backends we mostly care about web APIs that use HTTP.
Here is an example of a very simple HTTP API, for a weather service.
You, as a client, might send a request:
GET /weather?city=London HTTP/1.1
Host: api.example.com
Accept: application/jsonThe server might respond:
HTTP/1.1 200 OK
Content-Type: application/json
{
"city": "London",
"temperature_c": 18.5,
"conditions": "Cloudy"
}You do not know how it finds the temperature. It might call other services, read from a database, or do complex calculations. The API hides that complexity behind a simple contract:
- Endpoint:
/weather - Input:
cityquery parameter - Output: JSON object with
city,temperature_c,conditions
Why APIs Matter in Backend Development
As a backend developer, you will:
- Expose APIs for others to use
- Web frontends (React, Vue, mobile apps, etc.)
- Other backend services
- Third parties (for example partners and customers)
- Consume APIs provided by others
- Payment systems (Stripe, PayPal)
- Email services (SendGrid, Mailgun)
- Cloud storage (Amazon S3, similar services)
- Maps, geolocation, analytics, and many more
APIs let different systems:
- Communicate even if they are written in different languages
- Run on different machines or even in different countries
- Change internals without breaking users who follow the contract
Public, Private, and Partner APIs
APIs are used in different contexts. The contract idea is the same, but the audience changes.
Public APIs
- Available to anyone on the internet, often with registration and API keys.
- Examples:
- GitHub API
- Twitter / X API
- Weather APIs
- Currency exchange rate APIs
Use case: Third-party developers build apps that integrate with these platforms.
Private (Internal) APIs
- Used inside one company or one system.
- Not open to the public internet.
- Example:
- The frontend SPA calls your backend REST API.
- One microservice calls another microservice.
Use case: Structure a large system into well-defined parts with clear contracts.
Partner APIs
- Shared with selected partners, not the general public.
- Often use stricter authentication and custom contracts.
Use case: Two companies integrate their systems in a controlled way.
Types of APIs (High Level)
You will learn specific types later in the course, but here is a quick overview of common web API styles:
| Type | Key idea | Typical format |
|---|---|---|
| REST | Resources with URLs and HTTP methods | JSON over HTTP |
| GraphQL | Clients ask exactly for the data they need | JSON over HTTP |
| gRPC | Binary messages, very fast, often internal | Protocol Buffers |
| WebSockets | Two-way, real-time communication | Text / binary |
In this section of the course we focus on REST APIs, which use HTTP methods like GET, POST, PUT, and usually JSON.
Example: A Simple Library API
Imagine we are building a backend for a small library system.
We might design a simple API like this:
| Operation | HTTP Method | URL | Description |
|---|---|---|---|
| List all books | GET | /books | Get a list of all books |
| Get one book | GET | /books/{id} | Get details of one book |
| Add a new book | POST | /books | Create a new book |
| Update a book | PUT | /books/{id} | Replace info for one book |
| Delete a book | DELETE | /books/{id} | Remove a book from the system |
Example request to list all books:
GET /books HTTP/1.1
Host: api.library.com
Accept: application/jsonExample response:
HTTP/1.1 200 OK
Content-Type: application/json
[
{
"id": 1,
"title": "Clean Code",
"author": "Robert C. Martin",
"year": 2008
},
{
"id": 2,
"title": "Design Patterns",
"author": "Erich Gamma",
"year": 1994
}
]Again, the API does not show:
- How books are stored (PostgreSQL, MongoDB, a file).
- How the server is written (Python with FastAPI, Node.js, Java).
It only exposes what you can do and what you get back.
API as a Contract
Think of an API like a legal contract between:
- The API provider (your backend)
- The API consumer (a frontend or another system)
The contract includes things like:
- Endpoints: which URLs exist
- Methods: which HTTP methods are allowed (
GET,POST, etc.) - Inputs: what parameters, headers, and body shape are accepted
- Outputs: what the response looks like, usually JSON
- Status codes: how success and errors are represented
- Rules: for example limits, authentication, rate limiting
If the provider and consumer both respect the contract, everything works smoothly.
Important Rule:
Changes to an API must not silently break existing clients. You must manage changes carefully, often with versioning (for example /v1/..., /v2/...).
You will learn about API versioning and documentation in later chapters of the REST APIs section.
APIs and Abstraction
One of the main purposes of an API is abstraction.
Abstraction means:
- Hiding complex details
- Showing only what a user needs to know
Example:
- You have a
POST /paymentsAPI that charges a credit card. - Internally, it may:
- Talk to a bank
- Validate card numbers
- Handle exchange rates
- Store receipts in a database
- Externally, the client just sends:
POST /payments HTTP/1.1
Content-Type: application/json
{
"amount": 49.99,
"currency": "USD",
"card_token": "tok_12345"
}And receives:
{
"payment_id": "pay_98765",
"status": "successful"
}The API user sees a simple payment operation, not the full complexity.
This abstraction:
- Makes your system easier to use.
- Lets you change internal parts later without breaking clients.
- Helps you keep your code base modular and maintainable.
Common Misconceptions about APIs
“An API is a database”
Not exactly. A database is where data is stored. An API is a way to interact with a system.
An API might give you access to data stored in a database, but it can also:
- Do calculations
- Send emails
- Trigger background jobs
- Integrate multiple other APIs
“An API is just a URL”
A single URL is not an entire API. An API is the whole set of endpoints and rules.
You might have:
GET /usersGET /users/{id}POST /usersPUT /users/{id}DELETE /users/{id}
Together with the required JSON bodies, headers, and behavior, these form an API for user management.
“APIs are only for the web”
No. APIs exist in many forms:
- In-memory APIs between classes and modules in one application
- Operating system APIs (for example file operations, networking)
- Native libraries (for example a graphics library API)
In this course we focus on web APIs, especially RESTful APIs, because they are central to backend development.
A Small End-to-End Example
Let us put it all together.
You are building a Todo List web application.
- The user opens
https://todo.example.comin the browser. - The frontend JavaScript application loads.
- It wants to show the current user’s tasks, so it calls your backend API:
GET /api/tasks HTTP/1.1
Host: api.todo.example.com
Accept: application/json
Authorization: Bearer <token>- Your backend:
- Validates the token
- Looks up the user in the database
- Fetches the user’s tasks
- Sends back:
HTTP/1.1 200 OK
Content-Type: application/json
[
{"id": 1, "title": "Buy milk", "completed": false},
{"id": 2, "title": "Study backend development", "completed": true}
]The browser then:
- Reads the JSON data.
- Renders the task list on the page.
Your backend API:
- Exposes a clear contract:
GET /api/tasksreturns a list of tasks. - Hides internal details like database queries, authentication logic, etc.
Summary
- An API is an Application Programming Interface, a contract that defines how to interact with a system from the outside.
- It specifies what you can do, how to call it, and what you get back, without exposing internal implementation.
- In backend development, you mainly work with web APIs that use HTTP and JSON.
- APIs can be public, private/internal, or partner APIs.
- APIs provide abstraction, hide complexity, and allow separate systems to communicate reliably.
- As you move through this REST APIs section, you will learn how to design, build, and document such APIs in a clean, predictable way.
Views: 15
KAHIBARO