After this lesson, you will be able to: Explain what an API is, what REST means, and the HTTP verbs + statelessness rules at the heart of REST.
REST is the most common API style on the web. Most 'REST' APIs in practice are HTTP-JSON APIs that follow some REST conventions. This subtrack teaches you to design + build + consume them well.
This is a free introductory lesson. No purchase required.
API = Application Programming Interface. A contract that says: 'Send me this shaped data; I'll send you this shaped data back.' Web APIs = APIs you call over HTTP. The Stripe API, Twitter API, your own backend API your frontend calls. Without APIs, every system would talk in its own private protocol. With them, everything connects.
REST = Representational State Transfer. Defined by Roy Fielding in 2000. Core ideas: resources have URLs (/users/42), operations use HTTP verbs (GET / POST / PUT / PATCH / DELETE), responses are 'representations' of the resource (usually JSON), the server is stateless (each request stands alone). Pure REST also includes HATEOAS (hypermedia links in responses). Most production APIs skip HATEOAS, they're 'RESTish.' If you can build clean URL + verb + JSON APIs, you're REST-fluent enough for any job.
What each one means.
// GET, read a resource. Safe (no side effects), idempotent.GET /users → list usersGET /users/42 → get user 42// POST, create. Not idempotent (calling twice = two records).POST /users → create a user (body has the data)// PUT, replace the entire resource. Idempotent.PUT /users/42 → replace user 42 entirely// PATCH, partial update. Idempotent if done right.PATCH /users/42 → update only the fields in the body// DELETE, remove. Idempotent.DELETE /users/42 → delete user 42
Verbs in URLs: `POST /createUser` (use `POST /users` instead). Mixing PUT + PATCH semantics (PUT = full replace; PATCH = partial). Stateful APIs that fall apart when you scale horizontally. Using GET for actions with side effects (browsers + CDNs may pre-fetch GETs).