API
An API is the 'order counter' between frontend and backend, defining how the two communicate.
In one sentence
An API is the 'agreed-upon window' systems use to talk — it defines how to ask and what answer you get back.
In Plain Language
An API (Application Programming Interface) is the "agreed way to communicate" between two systems. The frontend wanting data can't barge into the backend's kitchen; it goes through the API counter: it makes a request in the agreed format, and the backend replies in the agreed format.
A good API has a clear contract: what the request must carry, what the response looks like, and what code is returned on error. With a clear contract, frontend and backend can be developed independently, and it's easier for AI to generate correct integration code.
Architecture
How It Flows
A Good Contract vs a Bad One
The difference between an API that's pleasant to build against and one that's a headache comes down to the contract.
- A good contract is clear (the request and response shapes are spelled out), stable (it doesn't change under you without notice), documented (you can look up what each field means), and versioned (a new version ships at
/v2/while/v1/keeps working). - A bad contract changes without warning and breaks everything depending on it, leaks internal details like raw database columns or stack traces, and has no documentation — so you discover its behavior by trial and error.
Common misconception: that the API and the backend are the same thing. The API is the agreed interface (the contract); the backend is the implementation behind it. As long as the contract holds, you can rewrite the backend — change its language or database — and the frontend won't even notice.
Key Takeaways
- API = the "agreed communication window" between systems.
- The contract is key: request format, response format, error codes.
- Version contract changes (e.g. /v1/, /v2/) so one change doesn't break everything.
An everyday analogy
An API is a restaurant's order counter: you order from the menu (request), the kitchen prepares and serves it (response), and both sides share the rules.
Pros
- Lets different systems connect cleanly
- One API can serve both web and app at once
- Clear contracts make collaboration easy for AI and humans alike
Cons
- Change the contract and both sides must change too (needs versioning)
- Poor design creates coupling that's hard to maintain
Good for
- Apps with separate frontend and backend
- Services meant to be integrated by third parties
Not for
- Purely static pages with no data exchange
Beginner scorecard
- Beginner-friendly
- 4/5
- Learning cost(higher = more cost)
- 3/5
- Market demand
- 5/5
- AI-generation friendly
- 5/5
Frequently asked questions
What exactly is an API?
It’s the “ordering counter” between systems: you send a request in an agreed format and get data back in an agreed format, without either side needing to know how the other works inside.
Can the frontend talk to the database directly without an API?
Strongly discouraged — that’s like handing every customer the warehouse keys. The API is the checkpoint in between that verifies identity and permissions and filters out data that shouldn’t leak.
Should I use REST or GraphQL?
For beginners and most projects, REST is enough — simple and intuitive. Consider GraphQL only when the frontend needs to flexibly combine lots of related data; don’t adopt it early just because it’s trendy.
Next in Beginner Path: DNS →