Challenge 2: Identify a Statelessness Violation — Possible Solution
====================================================================

WHY THIS VIOLATES STATELESSNESS
------------------------------------
The request GET /search/repeat carries NO information about what
query it's supposed to repeat — it only works because the server
remembers something from an earlier request (the "last search
query") in server-side session state. That's the exact opposite of
Chapter 3's statelessness constraint, which requires every request to
carry everything needed to understand it on its own, with nothing
relying on the server's memory of previous requests.

Two concrete problems this causes:
  1. If this request lands on a DIFFERENT server behind a load
     balancer than the one that handled the original search, that
     server has no idea what "the last search" even was — the whole
     approach breaks under horizontal scaling, which was one of the
     main benefits statelessness was supposed to provide.
  2. It's ambiguous for multiple users/sessions unless there's some
     separate identifier tying the "remembered" query to the specific
     client asking for it — which just reintroduces a session concept
     REST is trying to avoid.

THE FIX
------------------------------
Make the request self-contained by having the client simply resend
the actual search query every time, rather than relying on the server
to remember it:

  GET /search?q=laptops

Now the request means the same thing regardless of which server
instance handles it, and there's no server-side memory required at
all — exactly the property statelessness is meant to guarantee.

WHY THIS WORKS AS AN ANSWER
------------------------------
The giveaway in the original design is a request whose meaning
depends on something NOT included in the request itself. Any time an
endpoint's behavior depends on "whatever happened last time," that's
a statelessness violation, and the fix is almost always the same:
have the client explicitly include whatever information the server
was silently remembering.