We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Core Fundamentals
Free preview: the first 2 parts of this 13-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Core Fundamentals
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Every time you open Instagram, your phone makes about 30-50 REST API calls. Scroll through the feed, that's a GET request to /api/feed. Double-tap a photo, that's a POST to /api/posts/{id}/like. Pull down to refresh, another GET. Open someone's profile. GET /api/users/{username}.
Stripe processes billions of dollars through a REST API. Twilio sends millions of texts through one. Shopify runs over a million stores through theirs. GitHub, Slack, Discord, Spotify, Twitter, all REST APIs internally.
REST isn't just one way to build APIs. It's the way. Over 80% of public APIs are REST. When someone says "we need to build an API," they mean REST unless explicitly stated otherwise. It's the default. The standard. The thing you'll use a thousand times in your career.
And yet most developers can't explain why PUT and PATCH are different, when to use query parameters vs. Path parameters, or what a 409 Conflict status code means. They've been using REST for years without actually understanding it.
After this one, you'll know REST well enough to design a clean API from scratch and catch bad API design when you see it. That's a skill that separates professional engineers from people who just copy-paste endpoints.
REST stands for REpresentational State Transfer. Roy Fielding defined it in his 2000 PhD dissertation. The name is academic, but the concept is simple.
A REST API treats everything as a resource, a user, a post, an order, a product. Each resource has a unique URL. You interact with resources using standard methods. The server sends back representations of those resources (usually JSON).
That's it. Three ideas:
/users/42 is the user with ID 42REST is not a protocol. It's not a library. It's not a specification you can download. It's an architectural style, a set of constraints that, when followed, make APIs predictable, scalable, and cacheable.
The strength of REST is that anyone who knows HTTP already knows 80% of REST. HTTP has methods, status codes, headers, and URLs. REST just says: use them consistently and intentionally.