Ship it: conditional GET on the walkers index

fresh_when on a single record is easy. A collection needs a key.

show fingerprints one Walker — simple, Rails hashes the one record. index returns however many walkers match the query. fresh_when accepts a collection too, but a collection has no single updated_at to hash — Rails needs you to tell it what "freshness" means for the whole list.

The standard shape: key on the count, and the most recent updated_at in the set. If a walker is added, removed, or edited, at least one of those two numbers changes — so the ETag changes, and stale caches correctly miss. Nothing else about the list needs to change for the ETag to still catch it: renaming one walker bumps that walker's updated_at, which bumps maximum(:updated_at), which changes the fingerprint.

Where this wins

Picture a mobile client polling /walkers every 30 seconds so the walker list feels live. Most polls land on an unchanged list — no new walkers, no rating updates. Without conditional GET, every poll re-runs the query, re-serializes every walker, and ships the full payload over the wire. With it, most polls come back as an empty 304 in a fraction of the time, and the ones that DO carry new data are exactly the ones where something actually changed.