mediumConceptEntryMidSenior
Which status codes and method semantics do you insist on in a code review, how do the caching headers fit together, and is the API you just described REST?
6 min readUpdated 2026-08-15
Answer
Short answer
Get the method's safety, idempotency and cacheability right, use the status code intermediaries and clients act on rather than a generic 200 with an error body, pair Cache-Control freshness with ETag or Last-Modified validators, and be honest that most APIs called REST are resource-shaped HTTP without hypermedia.
Was this answer helpful?
Likely follow-ups
- A client sends If-Match with a stale ETag on a PUT. What do you return, and what should the client do with it?
- Why is 404 sometimes the right answer for a resource that exists?
- Your API sits behind a CDN and responses differ per authenticated user. What must you set, and what happens if you forget?
- When is POST the correct method for something that reads data?
Related questions
- Two clients open the same record, both edit it, and the second save silently overwrites the first. How would you use ETags to turn that lost update into something the client can see and handle?mediumAlso on etag and http4 min
- How do you design the error contract for an API that other teams have to program against?hardAlso on http and rest6 min
- Clients are asking for page 4,000 of your /orders collection. How is that endpoint paginated, and what would you change?mediumAlso on http and rest5 min
- You cached something in a module-level dictionary. It works on your laptop and behaves oddly in production. What is different?mediumAlso on caching5 min