Вы говорите про state приложение и его кэширование. Я говорю про кэширование отдаваемого содержимого. Сравните сложность решение с (готовым) кэшем между клиентом и сервером, и подключение распределенного кэша и его нормальное использование.
Плюс кэш перед приложением экономит ресурсы приложения.

Если нужен кэш "между клиентом и сервером", то достаточно адекватно отдавать заголовки Cache-Control и любой настроенный на кэширование хттп прокси закеширует контент (например nginx - https://nginx.org/ru/docs/http/ngx_http_proxy_module.html).
Правда тут сразу возникают практические нюансы:
1. Один и тот же URL может выдавать разный контент разным пользователям (надо учитывать аутентификацию)
2. В общем случае вы не можете адекватно предсказать когда отданный контент утратит актуальность.

Насколько я понимаю REST, то как раз могу.

В правильно разработанном приложении.

Ну а как вы предскажете это, практически?  Вот есть условный ФБ, есть мегапопулярный URL "моя лента".  Допустим мы даже не касаемся вопросов аутентификации, пусть этот URL у всех пользователей разный (типа /{user_id}/my) и реально аутентификацию в кэше не проверяем.
Как вы закешируете такой контент "между клиентом и сервером"?  Кто-то написал пост, это изменяет ленты у большого числа пользователей (а у ещё большего ничего не изменяет).   Вы же не можете предсказать когда это произойдёт.

Ну так вы описываете не rest приложение и спрашиваете меня, как применить rest подходы :)

Вопрос выше не зависитот того, рест приложение или нет.
Есть кеш уровня приложения, и там есть контроль над инвалидацией этого кеша.
Например, закешировалась лента новостей для пользователя. Когда появился новый пост, приложение для этом знает и инициирует инвалидацию кеша.
А случае, если кеш вне приложения, гдето ближе к пользователю, то начинаются всякие проблемы - вопрос с доступом, вопрос с инвалидацией.

Представим, что у меня был доступ к документу, я его запросил, и он закешировался где то перед приложением.
А потом у меня этот доступ отобрали. Но кеш не знает об этом, и я все равно смогу получить этот документ.
Неприятная ситуация.

Если у меня стоит классика и все ресурсы изменяются только через http снаружи и независимы друг от друга - то такой проблемы нет. Не для всех приложений подходит "чистый" rest. Начать с того, что там клиент stateless.

Ну так я хочу умный кэш. Чтобы я мог настроить сброс get entity/id по разным критериям. Которые получаем только из http

В чем с этим проблема?

В поиске такого умного кэша.

Мне только varnish в голову приходит.

Кэш - это не основа REST. Это один из необязательных компонентов реализации.

Кэш должен оправдывать своё существование. Он нужен обычно когда требуется интенсивное чтение одних и тех объектов.

Чем редис не подошел?

Тем, что руками инвалидировать надо?

Умным может быть агент, который отвечает за инвалидацию. То есть ваш код.

Я могу его поставить между браузером и приложением?

Я хочу не такого умного агента ))
Задача-то проста. Если пришел POST/PUT/... на /entity, то инвалидировать кэш на GET /entity.*?

Мне казалось, что это прям где-то готовое должно быть и при опеределенных условиях сильно снижать нагрузку на приложение.