REST APIs and Authentication Basics
How REST APIs organize functionality around resources and URLs, and how API keys and tokens prove who's calling.
What you'll learn
- Describe the core ideas behind REST: resources, URLs, and stateless requests
- Explain the conceptual difference between an API key and an auth token
- Explain why secrets should never be hardcoded into client-side code
Prerequisites
Explanation
REST (Representational State Transfer) is less a technology than a set of conventions for designing APIs so they're predictable. The central idea: everything an API manages is a resource, named by a noun, and reachable at a URL — like /books for the collection of all books, or /books/3 for one specific book. You already know the verbs that act on a resource, because they're just the HTTP methods from the previous lesson: GET /books/3 reads it, PUT /books/3 replaces it, DELETE /books/3 removes it, and POST /books creates a new one inside the collection.
Stateless is the other pillar of REST: each request must carry everything the server needs to understand it — the server does not remember anything about your previous requests just because they came from the same browser. This makes APIs easier to scale (any server instance can handle any request) and easier to reason about (nothing "invisible" affects the response). The one thing that looks like an exception is authentication: you resend proof of who you are with every request, rather than relying on the server to remember you from before.
Authentication answers "who is calling?" Two common mechanisms you'll meet constantly:
- API keys — a single, long-lived secret string identifying an application or account, usually sent in a header like
X-API-Key. Simple, but anyone holding the key can use it exactly as you can. - Auth tokens (often "Bearer tokens") — typically issued after a login step, often short-lived, and tied to a specific user or session rather than an entire application. Sent in a header like
Authorization: Bearer <token>.
Both prove identity by attaching a secret to the request rather than by the server remembering you — consistent with statelessness.
It's worth separating two ideas that sound similar: authentication ("who are you?") versus authorization ("what are you allowed to do, now that we know who you are?"). A valid API key might authenticate you successfully but still be authorized only for read access, for example.
Never hardcode secrets into client-side code. Any JavaScript that ships to a browser can be viewed by anyone who opens developer tools — there is no way to hide a string inside code the browser executes. Real secrets belong on a server, loaded from environment variables or a secrets manager, never bundled into a public app. Everything in this lesson's examples uses obviously fake placeholder keys for exactly that reason — you'll never see a real secret written directly into example code on this platform, and neither should your own client-side code.
Example
A mock authenticated API call — entirely local, using an obviously fake placeholder key to demonstrate the shape of the check.
// A mock REST endpoint that checks a fake API key before responding.
function callApi(path, apiKey) {
const VALID_KEY = "demo-key-123"; // placeholder only, never a real secret
if (apiKey !== VALID_KEY) {
return { status: 401, body: { error: "Unauthorized" } };
}
if (path === "/me") {
return { status: 200, body: { user: "ada", role: "admin" } };
}
return { status: 404, body: null };
}
console.log(callApi("/me", "wrong-key"));
console.log(callApi("/me", "demo-key-123"));Guided exercise
Guided exercise
Complete callApi so it returns { status: 200, body: { user: 'ada' } } when apiKey equals 'valid-key-999', and { status: 401, body: null } for any other key.
Checks: A valid key returns status 200 · The body includes user 'ada' · plus 1 hidden check
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Stuck? Get a hint.
Independent exercise
Independent exercise
Write callApi(path, apiKey) from scratch: with apiKey 'valid-key-999', GET '/profile' returns { status: 200, body: { role: 'admin' } }; with the same key, any other path returns { status: 404, body: null }; any wrong key, on any path, returns { status: 401, body: null }.
Checks: Valid key + /profile returns 200 with role admin · Valid key + unknown path returns 404 · plus 1 hidden check
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Stuck? Get a hint.
Common mistakes
- Storing API secrets directly in front-end JavaScript that ships to every visitor's browser.
- Assuming REST requires JSON specifically — REST is about resource-oriented URLs and HTTP semantics; JSON is just the overwhelmingly common data format choice.
- Confusing authentication (who are you) with authorization (what are you allowed to do).
- Reusing the exact same API key across development, staging, and production instead of separate keys per environment.
Knowledge check
Takeaway
REST organizes an API around resources and HTTP verbs, and every request proves identity on its own — never by leaning on secrets baked into client-side code.
Summary
REST APIs address resources with noun-based URLs and use HTTP methods to act on them, remaining stateless so each request is self-contained. Authentication (API keys, tokens) proves identity on every request, distinct from authorization, and real secrets must live server-side, never in client-side code.
References
Your notes
Notes save automatically.
Finished this lesson?
Mark it complete to track your progress and schedule a future review.
AI tutor
The optional AI tutor isn't enabled in this deployment. All lessons, exercises, quizzes, and search work fully without it.