An API (Application Programming Interface) is a contract that lets one piece of software talk to another. It defines what you can ask for and how to ask — methods, data formats, and rules — so that clients (apps, browsers, other services) can use your backend without knowing its internals.
High-level flow
A client sends a structured request (e.g. HTTP); the server interprets it, does work (e.g. DB, business logic), and returns a response. The API is the “surface” between them.
sequenceDiagram
participant C as Client (App/Browser)
participant API as API Layer
participant DB as Database / Services
C->>+API: Request (e.g. GET /users/1)
API->>API: Validate, auth, route
API->>DB: Query / business logic
DB-->>API: Data
API-->>-C: Response (JSON, status code)
Why APIs matter
Abstraction — Hide implementation; expose only operations and data the client needs.
Reuse — One backend can serve web, mobile, partners, internal tools.
Decoupling — Client and server can evolve independently as long as the contract is respected.
Types of APIs (by style)
REST — Resource URLs + HTTP methods (GET, POST, etc.).
GraphQL — Single endpoint; client asks for exact fields and shape.
gRPC — Binary, strongly-typed RPC over HTTP/2.
WebSocket — Full-duplex, real-time channel (often used alongside REST).