Diagnosis, exercises and capstone
Capstone: a reliable blog API
Combine semantics, security and diagnosis.
Understand the concept
Specify public reading and private administration separately. GET retrieves; use validators and suitable public caching with correct language variants. Admin updates combine If-Match, resource authorisation and safe errors. Do not share public and private cache assumptions.
Observe initial 200 and subsequent validation in DevTools. Test concurrent edits and a second-tab 412, then authentication, invalid bodies, rate limits and controlled timeouts. Test CORS with real browser origins, not only server-side clients.
Deliver a contract, redacted exchanges, a test matrix and a diagnosis report. Draw TLS/proxy trust boundaries. The course does not automatically alter application security; validate these designs in an isolated lab.
Turn protocol knowledge into tested engineering.
Treating one successful 200 as complete coverage.
FROM TERMS TO DECISIONS
What would you do with this request?
Choose an answer and read the reasoning. Revisit lessons for missed topics. Results only count correct answers to these questions; they are not a proficiency or security certification.
An API receives an expired Bearer token. Which response fits?
Answers remain in this page session; reading progress is stored separately in the browser.
One topic. Three levels of depth.
Public read → 200 + ETag → conditional GET → 304A cache-validation flow.
This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.
Try it yourself first.
Write at least four failure scenarios for the API.
Show the solution and explanation
Expired session → 401
Forbidden resource → 403
Stale ETag → 412
Invalid payload → 400
Exceeded limit → 429Verify status, safe error content and expected state protection for each case.