Exercise 3: Why This Must Be a PATCH, Never a GET — Possible Solution ==================================================================== WHY A STATE-CHANGING ACTION CAN'T BE A PLAIN GET ------------------------------ A GET request is meant to be safe and idempotent - something that can be triggered without the user's own deliberate intent, and repeated without consequence. Browsers and the broader web ecosystem rely on that assumption in ways a developer doesn't always see directly: link prefetching, crawlers following every link on a page, browser extensions that scan pages, or simply a user middle-clicking a link to open it in a new tab, can all issue a real GET request with no deliberate user action behind it. A CONCRETE EXAMPLE OF UNINTENTIONAL TRIGGERING ------------------------------ If "mark used" were implemented as a plain link - something like Mark Used - a browser's own speculative link-prefetching feature could fetch that URL in the background purely because the link appeared on a page the user was viewing, marking a real item used without the user ever clicking anything at all. The same risk applies to a search engine crawler indexing a page that happens to contain such a link. WHY PATCH AVOIDS THIS ------------------------------ A PATCH request can only be issued through deliberate code - here, a button's onClick handler calling fetch() explicitly. There's no browser behavior, crawler, or passive page-loading action that spontaneously issues a PATCH request the way many do issue GET requests. Requiring an explicit method for a destructive or state-changing action removes the entire category of accidental-trigger risk. WHY THIS WORKS AS AN ANSWER ------------------------------ It correctly explains the real semantic expectation behind GET (safe, no side effects) and gives a concrete, plausible mechanism - link prefetching - by which a GET-based version could fire without any real user intent, rather than describing the risk only in the abstract.