I Thought I Knew What an API Was. I Was Wrong.

For a long time, I had this feeling that I basically knew what an API was.

I mean, I’ve used APIs before.

In frontend projects, I used things like a weather API and got JSON data.
In backend, I created routes and heard people call them REST APIs.
Sometimes an API looked like a URL.
Sometimes it looked like a function.
Sometimes it looked like just a JSON response.

So I was honestly confused:

What is an API actually?
Is the weather JSON file the API?
Is an Express route the API?
Is an API just a way to fetch data?

Today I properly studied it, and finally the confusion became much smaller.

So this post is basically me sharing what I understood in simple words.

---

what is an API, really?

API stands for Application Programming Interface.

That sounds fancy, but the simple meaning is:

An API is a way for one software to talk to another software using defined rules.
That’s it.

Think of it like this:

• your frontend wants data
• your backend has that data
• the API is the way they communicate

Or:

• your app wants weather data
• some weather service has that data
• the API is the bridge between them

Real-life analogy

Imagine you are in a restaurant:

• You = client
• Kitchen = server
• Waiter = API

You don’t go inside the kitchen and cook by yourself.
You tell the waiter what you want.
The waiter takes the request to the kitchen.
Then the waiter brings the response back.

That waiter-like role is what an API does.

---

Then what was I misunderstanding in the weather app?

This was one of my biggest confusions.

When I make a weather app, I often do something like this:

fetch("https://api.example.com/weather?city=Kolkata")
  .then(res => res.json())
  .then(data => console.log(data));

And then I get something like:

{
  "city": "Kolkata",
  "temperature": 31,
  "condition": "Cloudy"
}

Earlier, I used to think:

“This JSON is the API.”

But that is not exactly correct.

---

What is actually happening?

• The API is the system/interface/endpoints/rules that let my app request data
• The JSON is the response format returned by the API

So the JSON is not the API itself.
It is the data sent back by the API.

That cleared up a lot for me.

Easy way to remember it

• API = the communication system
• JSON = one common format of the response data

So in a weather app, the API is not “a JSON file.”
The JSON is just the reply you get after using the API.

---

A backend route also feels like an API. Why?

Because it usually is.

For example:

app.get("/users", (req, res) => {
  res.json([
    { id: 1, name: "Pratik" },
    { id: 2, name: "Aman" }
  ]);
});

This route allows a client to request user data.

If a frontend sends a request to /users, the backend sends a response.

That route becomes part of your API.

So yes, when I build backend routes, I am often building an API.

---

So what is the simplest definition I should remember?

Here’s the definition I’ll remember from now on:

An API is a set of rules and endpoints that allows one software system to communicate with another.

And in web development:

An API usually lets a client send a request and receive a response.

---

Types of API

This part also confused me because people say “types of API” in different ways.

Sometimes they mean who can use the API.
Sometimes they mean how the API works.

So I’ll keep both simple.

---

1) Public API

A public API is available for external developers to use.

Example

A weather service giving data to developers.

Use case

You are building a weather app and want live temperature data.

fetch("https://api.weather-service.com/current?city=Delhi")

You are using someone else’s public API.

---

2) Private API

A private API is used only inside an organization or company.

Example

An admin dashboard talking to the company’s internal backend.

Use case

A company has internal employee data, sales data, analytics, etc.
That API is not open for the whole world.

---

3) Partner API

A partner API is shared only with selected business partners.

Example

A payment company allowing trusted partner apps to connect to its services.

Use case

An e-commerce platform integrating a shipping provider’s partner API.

---

4) REST API

This is the type I hear the most in backend development.

A REST API is a web API that uses HTTP methods like:

• GET
• POST
• PUT
• PATCH
• DELETE

Example

app.get("/products", (req, res) => {
  res.json([{ id: 1, name: "Laptop" }]);
});

app.post("/products", (req, res) => {
  res.status(201).json({ message: "Product created" });
});

Use case

Most CRUD apps:

• users
• posts
• products
• comments
• tasks

REST is common because it is simple and structured.

---

5) SOAP API

SOAP is older and more strict than REST.

It often uses XML instead of JSON and follows stricter rules.

Example use case

Banking systems, enterprise systems, older business software

SOAP is less beginner-friendly, but it still exists in some places where strict standards matter.

---

6) GraphQL API

With GraphQL, the client can ask for exactly the data it needs.

Example

Instead of getting a big object, you can request only specific fields.

{
  user(id: 1) {
    name
    email
  }
}

Use case

Apps where over-fetching or under-fetching data is a problem

For example, if you only want name and email, GraphQL helps you avoid receiving unnecessary data.

---

7) WebSocket API

This is useful when you want real-time, two-way communication.

Example use case

• chat apps
• live notifications
• multiplayer games
• stock price updates

Unlike normal request-response flow, WebSockets keep the connection open.

---

The easiest way I now think about it

If someone asks me about API types, I’ll think like this:

Based on access

• Public
• Private
• Partner

Based on style/communication

• REST
• SOAP
• GraphQL
• WebSocket

That makes the topic much less messy in my head.

---

A little about status codes

When a client sends a request to a server, the server responds with not just data, but also a status code.

That code tells us what happened.

Example:

app.get("/profile", (req, res) => {
  res.status(200).json({ name: "Pratik" });
});

Here, 200 means the request worked successfully.

Status codes are super useful because they quickly tell us whether:

• the request succeeded
• something was missing
• access was denied
• the server crashed

---

Tiny example: request + response + status code together

Here’s a super small Express example:

app.post("/login", (req, res) => {
  const { email, password } = req.body;

  if (!email || !password) {
    return res.status(400).json({ error: "Email and password are required" });
  }

  if (email !== "[e-mail]" || password !== "1234") {
    return res.status(401).json({ error: "Invalid credentials" });
  }

  return res.status(200).json({ message: "Login successful" });
});

This one route already shows a lot:

• 400 if input is missing
• 401 if credentials are wrong
• 200 if login works

That made status codes feel much more practical to me.

---

What I finally understood today

If I explain it to my old confused self, I’d say:

• API is not just JSON
• API is not just a backend function
• API is not just a URL
• API is the communication bridge with defined rules

And the JSON in apps like weather apps is usually just the response data returned by the API.

That one difference cleared up a lot of confusion for me.

---

Final summary

Today I finally stopped treating “API” like a vague buzzword.

What I learned is:

• an API lets one software communicate with another
• in web development, APIs usually work through request and response
• the JSON we get is usually the response, not the API itself
• backend routes often become part of our API
• APIs can be public, private, partner-based, or different in style like REST, SOAP, GraphQL, and WebSocket
• status codes help us quickly understand what happened after a request

This was one of those topics I thought I already understood, but actually needed to sit down and study properly.

And honestly, now it feels way less scary.