Политика управления кешем для поискового ресурса в RESTful API

Question

Я создаю RESTful API (используя MVC.NET), чтобы разрешить внешний доступ к бизнес-системе. API включает в себя поисковый ресурс. Ресурс принимает форму URI "/ example / search / pages / 1 /? Query = кое-что".

Пример. Для поиска пиццы вы должны получить доступ к URI "/ example / search / pages / 1 /? Query = pizza", который даст вам первые 10 результатов. Чтобы получить вторую страницу результатов, вы должны запросить «/ example / search / pages / 2 /? Query = что-то» и т. Д.

Я использовал заголовок HTTP для управления кэшированием, чтобы включить публичное кэширование всех ресурсов API с целью значительного снижения нагрузки на сервер (ы), обслуживающий веб-приложение API.

Однако я не уверен, какую политику кэширования использовать для поискового ресурса. Поскольку ресурс (и его URI) различаются в зависимости от того, что вы ищете, кажется, что нет смысла кэшировать страницу. Какую политику кэширования (т. Е. Кэширование с помощью HTTP-заголовка управления кэшированием) люди рекомендуют для ресурсов поиска по API RESTful? Нет кеширования? Частное кэширование с очень коротким сроком действия? Публичное кеширование с коротким сроком действия?

Answer 1

Большинство прокси не кэширует ничего, что использует строку запроса.

Если вы хотите кэшировать, я бы предложил создать новые URI для вашего поискового запроса с использованием шаблона POST-Redirect-GET.

POST поиск Тип контента: application / x-www-form-urlencoded

Термин = что-то

303 См. Другое Местоположение: / поиск / что-то / 1

Это позволит более агрессивно кэшировать, но вам придется создать эти URI и все равно получить удар при первоначальном POST. Тем не менее, если это вопрос, который проблематичен, это хорошо решит проблему.

Answer 2

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

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

Это не было частью вашего вопроса, но на вашем месте я бы переместил нумерацию страниц в часть запроса URI, поэтому

/ пример / поиск / страницы / 1 /? = Запрос что-то

станет:

/ пример / поиск? Термин = кое-что и страница = 1

Это не существенно, но будет более интуитивно понятным для разработчиков, и вы можете упростить задачу с помощью HTML-формы