Understand REST in plain words — an API is a way for programs to talk over the web. Learn what a resource is, why URLs should be nouns, and why every request stands on its own (stateless).
An API (Application Programming Interface) is just a way for one program to ask another for data or actions over the web — the same web your browser uses, but the answers come back as data instead of a web page. REST (Representational State Transfer) is the most common set of rules for designing that conversation. The core idea: everything your API exposes is a "resource" — a thing you can name, like a user or an order — and each resource lives at its own URL. You read and change resources by sending HTTP requests to those URLs.
// Think in NOUNS (things), not verbs (actions).
// Each line below is a resource at its own address (a "URL").
GET /users // the collection of all users
GET /users/42 // one user, the one with id 42
GET /users/42/orders // the orders that belong to user 42
// Anti-pattern: putting the action in the URL.
// REST puts the action in the HTTP METHOD instead (next lesson).
GET /getUser?id=42 // avoid
POST /createUser // avoid
POST /deleteUserById/42 // avoidStateless means the server keeps no memory of your previous request. Each request must carry everything the server needs to handle it — who you are (an auth token) and what you want. This sounds limiting, but it is what lets an API scale: any server in a pool can answer any request, because no single server is holding your "session" in memory. If you have ever heard "the API is stateless," this is all it means.
// Every request is self-contained. The server learns WHO you are
// from the token on THIS request, not from a memory of the last one.
GET /orders HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1... // who you are
Accept: application/json // what format you want
// Because nothing is remembered between calls, the same request
// sent twice will behave the same way. That predictability is the
// whole point — and it is why auth lives on every request.
// (Logging users in is its own topic — see the Authentication course.)A resource is the underlying thing (user 42). A "representation" is how that thing is shown to you in a response — almost always JSON (JavaScript Object Notation), a simple text format of keys and values that every language can read. The resource lives in your database; the JSON is a snapshot of it sent over the wire. Keeping these separate in your head matters: you can change how you store data without changing the JSON your API promises to return.
// The resource: a row in your database (you control this privately).
// The representation: the JSON you send back (a public promise).
// GET /users/42 -> 200 OK
{
"id": 42,
"name": "Ada Lovelace",
"email": "ada@example.com",
"createdAt": "2026-01-04T09:30:00Z"
}
// Note what is NOT here: no password hash, no internal flags.
// You choose what the representation exposes — never just dump the row.