Элегантные методы для кэширования результатов поиска от сервиса RESTful?

Question

У меня есть веб-сервис RESTful, к которому я обращаюсь из браузера, используя JavaScript.В качестве примера, скажем, что этот веб-сервис возвращает список всех ресурсов сообщений, назначенных мне, когда я отправляю запрос GET в / messages / me.Из соображений производительности я бы хотел кешировать этот ответ, чтобы мне не приходилось повторять его каждый раз, когда я захожу на веб-страницу управления сообщениями.Срок действия кэшированного ответа истечет через 5 минут.

Если ресурс Message создается «за моей спиной», скажем системным администратором, возможно, что я не буду знать об этом в течение 5 минут, покасрок действия кэшированного поискового запроса истекает, и он снова выбирается.Это приемлемо, потому что это не создает путаницы для меня.

Однако, если я создаю новый ресурс сообщений, который, как я знаю, должен быть частью ответа на поиск, он становится запутанным, когда его нет в моих сообщениях управления.страница сразу.В общем, когда я сознательно создаю / удаляю / обновляю ресурс, который делает недействительным кешированный ответ на поиск, мне нужно, чтобы этот кешированный ответ немедленно истекал / очищался.

Основная проблема, которую я не могу понять:1007 *

Я не вижу простого способа связать задачу создания / удаления / обновления ресурса с задачей истечения срока действия соответствующих кэшированных ответов.В этом примере это кажется простым, я мог вручную истечь кешированный ответ поиска каждый раз, когда я создаю / удаляю / обновляю (ny) ресурс Message.Но в более сложной системе отслеживание того, какие ответы на поиск истекают при каких обстоятельствах, быстро станет неуклюжим.

Answer 1

Кэш браузера должен автоматически сделать недействительным кеш, когда вы выполняете POST с тем же URI, с которого вы сделали GET. См. эту статью, в частности, раздел о недействительности POST.

Answer 2

Используйте E-Tag и If-None-Match заголовки , чтобы обеспечить постоянный доступ клиента к самой актуальной информации.

Недостатком этого является то, что вывсегда звоните на сервер, чтобы узнать, изменилось ли что-нибудь.Все сообщение не будет передано повторно, если ничего не изменилось, и в этом случае сервер просто / просто ответит ответом 304 Not Modified.Если содержание изменилось, то новое сообщение будет передано в качестве ответа.

Если сервер реагирует (10-50 мс), то большинство пользователей с приличной задержкой (50-500 мс)не должно видеть заметной разницы.

Это увеличивает нагрузку на сервер, поскольку для каждого запроса он должен будет проверять, соответствует ли полученный E-Tag текущему E-Tag для этого ресурса.Клиенты никогда не предполагают, что ресурс действителен / устарел / просрочен, они всегда проверяют связь с сервером и выясняют.

Answer 3

Цитируя Фила Карлтона: «В компьютерных науках есть только две серьезные проблемы: аннулирование кэша и присвоение имен».

Если вы используете всеобъемлющий уровень доступа к данным, это было бы местом для обработки кэша.аннулирование (хотя это все еще не легко).Вы просто привязали бы некоторую логику аннулирования кэша к своей логике для сохранения сообщения, чтобы он очищал кэш поиска для получателя сообщения.

Answer 4

Самое простое решение - использование кэша на стороне сервера (например, EhCache) :) У вас будет меньше проблем с согласованностью (так как вам не нужно вносить изменения в JavaScript) и с истечением срока действия.