Рекомендации по кешированию для коллекции REST и отдельных элементов

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

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

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

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

Могу ли я:

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

ЗА:

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

Минусы:

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

ИЛИ

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

ЗА:

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

МИНУСЫ:

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