(Этот ответ приходит спустя десятилетие после первоначального вопроса - но, учитывая, что я сталкиваюсь с этим вопросом в более крупных организациях, с которыми я консультируюсь, я решил, что здесь полезно объяснить.)
Когда Рой Филдинг посмотрел на SOAP , он понял, что если бы Методы HTTP (GET, POST и т. Д.) Были используется для доступа к ресурсам и их изменения, а не только для использования HTTP для простых удаленных вызовов процедур, тогда можно использовать остальные спецификации HTTP, такие как кэширование ( RFC-2616 ). Многоуровневая архитектура Филдинга иллюстрирует это. Вот почему он придумал ОТДЫХ .
В качестве прокси-сервера для кэширования HTTP Squid - это та реализация, которая может значительно снизить нагрузку на ваши бэкэнд-системы, а также обеспечить актуальность кэшированных данных.
Стандарт позволяет определить, как долго кэшируется элемент до его повторной проверки, и как делать условные запросы, поэтому в ответ на запрос отправляются только новые версии. Все это поведение клиента уже реализовано в браузерах и в клиентах HTTP, используемых на основных языках, таких как Java *1025* и сопутствующая библиотека кэширования .
Java *1025* Apache HttpComponents.
Поскольку все эти механизмы были четко определены и реализованы к настоящему времени, их использование на самом деле является лишь вопросом использования этих компонентов, большинство из которых вы, возможно, уже используете (например, на момент написания статьи Apache HC Components реализация по умолчанию, которая поставляется с SpringBoot - просто добавьте библиотеку кэширования в сборку).
Если вы захотите реализовать это с помощью MemCache или Redis , вы просто заново изобретаете колесо и с тех пор будете постоянно поддерживать этот код. И если вы не внедрите эквивалент RFC 2616 в коде, вы будете использовать устаревшие данные с неэффективной связью.