What Makes API Design Its Own Discipline
You'll learn to
- -Explain why API design is graded separately from HLD and LLD in an interview loop, even though all three overlap
- -Recognize the three protocol families (REST, GraphQL, gRPC) this course covers and when each one is the right default
An API is a contract: a promise about what requests look like, what responses look like, and what happens when something goes wrong - kept stable enough that thousands of client applications you'll never see can depend on it without breaking every time you ship a change. API design is the discipline of writing that contract well, and it is graded on its own in interview loops precisely because it is a genuinely different skill from HLD (how the system scales) or LLD (how the code inside one service is structured).
A Contract, Not Just an Interface
A function signature is a contract between two pieces of code you control and can change together. An API is a contract between your service and clients you do not control and cannot force to update - a mobile app on a user's phone, a partner's backend integration, a script someone wrote three years ago. That asymmetry is what makes API design hard: every decision has to account for a client on the other end that might never see your next deploy.
Three Protocol Families, Three Different Trade-offs
- -REST: resource-oriented, built on HTTP verbs and status codes, the default for public APIs and most internal service-to-service calls - simple, cacheable, universally understood.
- -GraphQL: client-specified queries against one schema, letting each client fetch exactly the fields it needs in one round trip - strong for products with many different frontends (web, mobile, third-party) pulling different shapes of the same data.
- -gRPC: binary, strongly-typed, built on HTTP/2 - the default for internal service-to-service calls where performance and strict contracts matter more than human-readability or browser support.
This course follows the API Design Lab's own progression: REST fundamentals first (Acts 1-2), then GraphQL (Act 3), then gRPC and event-driven patterns (Act 4), then full systems that combine all three (Act 5) - the same order real engineers tend to encounter these technologies, from the most universal to the most specialized.
A recurring theme in this course: the "best" protocol is never absolute, it depends on who the client is and what they need. Part of what an API design interview actually grades is whether you can name that trade-off instead of defaulting to whichever protocol you personally know best.
An interviewer asks: "Why would you choose GraphQL over REST for this product?"
"GraphQL is more modern and flexible, so it's generally the better choice."
"It depends on the client landscape - if we have several different frontends (web, iOS, a partner integration) that each need different slices of the same underlying data, GraphQL lets each one query exactly what it needs without us maintaining several REST endpoints or over-fetching. If we mostly have one client and a simple, cacheable resource model, plain REST is usually simpler to build, cache, and debug."
Why is API design treated as a distinct interview skill from HLD or LLD?