Особенности кэширования коллекции REST и отдельных элементов - PullRequest
Новая
       17

Особенности кэширования коллекции REST и отдельных элементов

5 голосов
/ 27 октября 2011

Я работаю над новым REST-ful API, основным / единственным потребителем которого будет умный / не веб-браузерный клиент. У меня есть ресурс коллекции, который поддерживается / обновляется фоновыми процессами, а не самим клиентом. Единственный тип контента, необходимый для первой итерации, - это JSON. URI - это что-то вроде:

  • /items/ - Ресурс, представляющий коллекцию предметов.
  • /items/123 - Ресурс, представляющий отдельный элемент с идентификатором 123.

Хотя клиент не будет создавать новые элементы или обновлять коллекцию для добавления / удаления элементов, он будет обновлять некоторые значения в отдельных элементах. Я планирую использовать HTTP PATCH для обновления ресурсов элементов, используя мой собственный формат патчей JSON.

Будет много одновременных клиентов, читающих элементы, и одновременных обновлений для различных элементов, со случайными параллельными обновлениями для одного и того же элемента, и хотя определенная степень «возможной согласованности» разрешена, я хотел бы оформить это как «дружественный кеш» способ, насколько это возможно. Читая RFC для PATCH, я вижу, что при успешном ответе на PATCH кэш запроса-URI должен обновляться ответом, если он есть. Вопрос сводится к:

Должен ли я:

A) включить полное представление отдельных элементов в представление JSON ресурса сбора /items/ и отправить PATCH на URI /items/ и включить элемент для обновления в формате исправления?

ПЛЮСЫ:

  • Это позволяет клиенту не выполнять N количество запросов только для отображения списка ресурсов
  • позволяет любому кешу items быть недействительным, когда клиент обновляет элемент.

МИНУСЫ:

  • Это не так "чисто" для меня, так как я на самом деле не обновляю коллекцию, а отдельный предмет.
  • Это делает недействительным кеш всей коллекции вместо кеша одного измененного элемента.

OR

B) В представлении JSON коллекции ресурсов включайте только ссылки на включенные элементы, и пусть клиент запрашивает отдельные элементы после обнаружения, какие из них находятся в коллекции. HTTP PATCH будет отправлен на URI отдельного элемента (например, /items/123)

ПЛЮСЫ:

  • Кэширование ресурсов коллекции и предметов независимо. PATCH отдельного элемента может корректно аннулировать кэш только этого элемента.
  • API более понятен, поскольку вы запускаете HTTP PATCH для определенного элемента, который хотите обновить.

МИНУСЫ:

  • Запрещает пакетное обновление элементов. В настоящее время это вообще не является обязательным требованием, и я не предвижу его в будущем, но только ретроспективно это 20-20.
  • Требуется, чтобы клиент выдал N+1 запросов на отображение полного списка элементов.

Ответы [ 2 ]

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

У меня когда-то было похожее требование, клиент хотел знать последние обновленные элементы.Для этого я добавил в свой ресурс коллекции параметр «последнее обновление»: 


GET /items?modifiedAfter=2011-10-10/10:10:10

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

Попытка работать с PATCH и кэширование в коллекциях была очень сложной и далекой от тривиальной (работа со стандартными заголовками E-Tag, показ «правильных» объектов и т. Д., Реализация на жестком клиенте).Основная проблема заключается в том, что коллекции часто имеют очень динамичное и изменяющееся поведение.

В конце концов работа с modifiedAfter на ресурсах коллекций была довольна как для сервера, так и для клиента API.

Помимовопрос кеширования оцените, действительно ли вам нужны частичные обновления.В большинстве случаев я предпочитаю более простое полное обновление (используя PUT).

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

Я бы пошел на B. Но вы, клиенты, обычно запрашиваете всю коллекцию (я имею в виду, нужна ли им коллекция)?в противном случае опция A будет генерировать слишком много трафика.И аннулирование кэша происходит для всех элементов (как они есть в коллекции).

Если ваши клиенты в основном получают всю коллекцию, тогда A с параметром запроса для конкретного элемента также вариант.

...