REST API Cache caches REST responses keyed by route, query, and (optionally) capability. Entries land in a dedicated rest_api_cache table (or equivalent option-backed store depending on configuration) with columns for route, hash, payload, hit count, TTL, and last accessed timestamp. The default admin shows aggregate hit rate and a flush button, which is enough for the simple case and not enough for diagnosing why one route is a cold cache and another is doing 95 percent hits.

SleekView reads the cache table directly and exposes each entry as a row. The route, query digest, TTL, hit count, miss count, and last accessed timestamp all become first-class columns. Aggregations roll up by route to show hit ratio across all variants of a given endpoint, so the cold /wc/v3/orders?customer=... entries and the hot /wp/v2/posts entries each surface clearly.

Inline edits support changing TTL, manually invalidating entries, and pinning long-lived rows. Writes go through the plugin's own purge and update API where available; manual TTL changes record an audit row. Bulk purging by route or by TTL range happens from the table without writing custom WP-CLI scripts.

REST API caches are the difference between an origin that survives traffic and an origin that buckles under it. REST API Cache does the hard part well: keying responses, honoring TTLs, and offloading to object caches when available. The dashboard shows an aggregate hit rate, which is fine for marketing slides and useless for operations.

A 70 percent aggregate can mean every public route is fully cached and every private route is cold, or it can mean the cache is half-effective everywhere. The data to tell the difference is in the cache table, broken out per route and per variant. SleekView pivots that table into rows: route, variant count, hit ratio, TTL, and last accessed timestamp.

The hot routes sort to the top. The cold ones sort to the bottom. Tuning the cache stops feeling like guesswork and starts feeling like editing a spreadsheet.