Practice this topic in a realistic system design interview
REST remains the default API style for public web APIs, product backends, partner integrations, and many internal services. It works because HTTP is everywhere, the tooling is mature, JSON is easy to inspect, and clients can usually call the API without generated code.
That familiarity can hide design mistakes. A REST API with inconsistent resource names, vague status codes, unsafe retries, unlimited list endpoints, and one-off error responses becomes expensive to use. Clients add workarounds. Server teams become afraid to change behavior. Every new endpoint copies old mistakes.
Good REST API design is mostly disciplined use of HTTP: clear resources, predictable request and response bodies, correct methods, useful status codes, meaningful headers, caching, authentication, and clear rules for change.
This chapter covers the principles of REST API design, from resources and methods to status codes, caching, and versioning.