Exercise 2: The Real Problem With a GET-Triggered Mark-Used Link — Possible Solution
====================================================================

THE REAL PROBLEM
------------------------------
HTTP's own semantics treat GET requests as safe and non-mutating - something that's expected to be triggerable without the user's deliberate intent, since browsers, crawlers, and various automated tools routinely issue GET requests on their own (following links, prefetching pages a user merely hovers over, or replaying a request from cached browser history). If mark_used is wired up behind a plain GET link, any of those automated or incidental GET requests could trigger the actual state change - marking a real item as used - without any genuine user action behind it at all.

A CONCRETE SCENARIO
------------------------------
A browser's link-prefetching feature loading a page in the background because the user merely hovered over or glanced near a "Mark Used" link, without ever actually clicking it, could still issue the GET request and silently mark that item used - a real, unintended state change the user never asked for.

THE FIX
------------------------------
Make mark_used only respond to POST requests, triggered by an actual form submission (even one with no additional input fields, just a submit button) rather than a plain anchor link - this matches HTTP's own expectation that mutating actions require an explicit POST, not a GET.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains why GET requests are expected to be safe/non-mutating and can be triggered incidentally by browsers or automated tools, gives a concrete, realistic scenario (link prefetching) where this could cause an accidental state change, and correctly identifies switching to a POST-only form as the fix.