RESTful дизайн: использовать ETag и If-None-Match для получения новых элементов в коллекции? - PullRequest
Новая
       13

RESTful дизайн: использовать ETag и If-None-Match для получения новых элементов в коллекции?

2 голосов
/ 29 октября 2011

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

I 'Меня интересуют ваши отзывы о следующем подходе:

  1. Набор элементов представлен на URI http://foobar.com/items
  2. Клиент, делающий начальный запрос GET на этот URI, не будетзаголовок If-None-Match.В этом случае сервер возвращает все элементы (или некоторую сумму по усмотрению сервера, скажем, самые последние N элементов).Ответ содержит заголовок Etag, указывающий «тиковый штамп», который представляет текущее псевдо-время псевдо-часов сервера (например, некоторый счетчик, который увеличивается каждый раз, когда происходит изменение в данных).
  3. Клиент кэширует возвращенные элементы.
  4. При последующих запросах GET клиент включает ранее полученное значение Etag в свой заголовок If-None-Match.Сервер проверяет, есть ли у него какие-либо элементы, более новые, чем заголовок If-None-Match, и, если это так, возвращает ТОЛЬКО более новые элементы.В противном случае он возвращает статус 304 («не изменен») и никаких элементов.

Вопрос - я подрываю семантическое значение GET, возвращая только новые элементы в # 4, а невся коллекция (которая будет включать элементы, уже кэшированные на клиенте)?Или это похоже на разумный подход?Можете ли вы предложить альтернативные подходы, которые были бы лучше?

Заранее спасибо.

1 Ответ

2 голосов
/ 30 октября 2011

Обычно клиент должен выполнить сравнение ETAG после запроса HEAD и, если необходимо, выполнить более конкретный запрос (запрос диапазона или запрос записей, более новых, чем определенная отметка времени). Там сервер должен просто обслуживать запрошенные ресурсы.

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

...