These questions cover the 17 sections of the REST API Design overview and are organized into 5 topic clusters. No answers are provided — the goal is to test your understanding of REST principles, HTTP semantics, API design trade-offs, and implementation choices.
The questions mix conceptual understanding, protocol mechanics, and architectural decision-making.
Explain the REST principle "URLs are nouns, HTTP methods are verbs." Map each CRUD operation to its HTTP method and explain why POST goes to the collection URL while PUT/DELETE go to the item URL.
Rate the following URLs from most to least RESTful and explain why: GET /api/books/1, GET /api/books?id=1, GET /api?record=books&id=1, GET /api?id=1&action=delete. What makes the last one "definitely not REST"?
A developer returns 200 OK for every response, including errors, and puts the actual status in the JSON body: {"status": "error", "message": "not found"}. Why is this problematic? What HTTP status codes should they use instead?
Explain the difference between 400 Bad Request, 401 Unauthorized, 403 Forbidden, and 404 Not Found. Give a concrete scenario for each in a books API.
Why does a successful POST return 201 Created instead of 200 OK? What is the purpose of 204 No Content, and when would you use it?
Compare PUT and PATCH: what happens to fields you don't include in the request body for each method? Why is PUT idempotent but PATCH is not guaranteed to be? Give an example where PUT and PATCH produce different results.
The overview says "REST is explicitly format-agnostic." Explain what this means using the Content-Type and Accept headers. Why should an API accept application/x-www-form-urlencoded in addition to application/json?
Explain content negotiation: how does a single endpoint like GET /api/books serve JSON to a JavaScript client, HTML to a browser, and CSV for a data export? What header drives this behavior?
HTML forms only support GET and POST. How do you perform a PUT or DELETE operation from a web page? Describe at least two workarounds and their trade-offs.
A corporate proxy strips PUT and DELETE requests. The overview describes X-HTTP-Method-Override as a workaround. How does it work, and why does using HTTPS make this problem go away?
Describe the four levels of the Richardson Maturity Model. Most modern APIs target Level 2 — what would you need to add to reach Level 3, and why do most teams stop at Level 2?
What is HATEOAS? Show how a response for GET /api/books/42 would look with HATEOAS links. How does the GitHub API demonstrate HATEOAS in practice?
Compare private vs public API design: why is versioning "often unnecessary" for private APIs but "essential" for public ones? What breaks if you make a backward-incompatible change to a public API?
The overview describes three versioning strategies: URL path (/v1/api/books), header (Accept: application/vnd.myapi.v2+json), and query parameter (?version=2). Compare their trade-offs. Which is most common and why?
Explain the "Bezos API Mandate": why should you design every API as if it might become public? What design habits does this force?
Explain the Same-Origin Policy and why browsers enforce it. What is a "preflight" OPTIONS request, and when does it happen? Why is CORS a browser-side enforcement, not a server-side block?
Why is Access-Control-Allow-Origin: * dangerous in production? What should you use instead, and what additional CORS headers are needed for PUT/DELETE requests?
json-server generates a full CRUD API from a JSON file. What is its intended use case, and why does the overview say it "teaches you nothing about how APIs actually work"? When would you use it vs building a real API?
Explain "design-first" vs "code-first" API development with OpenAPI. How does writing the spec first enable parallel frontend/backend development? What problem does spec drift cause?
The API testing checklist includes: happy path, error cases, status codes, response shape, edge cases, auth, and idempotency. Pick three and explain what specific tests you'd write for a POST /api/books endpoint.
The side-by-side table shows Node.js uses req.body while PHP uses json_decode(file_get_contents('php://input'), true) to read JSON. Why the difference? What does php://input represent, and why can't PHP just use $_POST for JSON?
The overview states the "most important architectural difference" between Node.js and PHP REST APIs is data persistence. Explain: why can Node.js store data in a variable while PHP must use files or databases?
REST struggles with batch operations, complex queries, real-time data, and non-CRUD actions. Pick two and explain the specific problem. How does GraphQL solve the over-fetching and under-fetching problems?
Compare REST, GraphQL, and gRPC across three dimensions: data format, number of endpoints, and browser support. When would you choose each one?
The overview warns about the "distributed monolith" anti-pattern. What is it, and how does REST between microservices create problems that REST between client and server doesn't? What does "error cascading" mean in this context?