Почему разные этаги для разных представлений одного и того же ресурса?

Я понимаю использование etags для оптимистического управления concurrency (например, в стиле архитектуры RESTful), и я прочитал, что etags должны отличаться для разных представлений одного и того же ресурса. Почему это?

В конечном итоге нам не интересно узнать, изменился ли ресурс, поэтому мы можем обрабатывать одновременные изменения? Мне нелегко даже представить, когда представление ресурса изменится без изменения самого ресурса, поэтому я, очевидно, не понимаю базового понимания.

Ответ 1

Хороший вопрос, и я думаю, что это вопрос некоторых дебатов.

Я думаю, что большинство скажет, что ETag представляет не только версию ресурса, но и тип контента. Это имеет смысл для кеширования ответов на основе типа контента, языка и т.д.

Ознакомьтесь со следующими ссылками:

Раздел статьи Википедии о сильных против слабых ETags: http://en.wikipedia.org/wiki/HTTP_ETag#Strong_and_weak_validation
Информативное обсуждение кодировки содержимого и ETags: http://www.gossamer-threads.com/lists/apache/dev/339577

Ответ 2

Это не вопрос дебатов, когда вы излагаете факты или когда читаете спецификацию HTTP & HTTPbis.

ETag - это средство кэширования и управление concurrency. Слабые ETags - это всего лишь средство кэширования малоимущих.

В терминах кеширования (GET) - uri + content-type + etag может помочь вам сэкономить пропускную способность, не отвечая на полезную нагрузку, а просто с кодом статуса 304.

В терминах управления concurrency (POST; PUT; PATCH) - стремительно иметь ETag, рассчитанный на основе URI + content-type + бит-точного ответа. Почему?

Если вы вычисляете ETag на основе целого объекта, надмножество полезной нагрузки ответа (т.е. ваша полезная нагрузка дает + b, но объект на самом деле является + b + c), тогда выполнение PATCH, например, завершится потому что ETag изменился... вы обновляете.. вы получаете одни и те же данные, но другой ETag... вы повторите PATCH с новым ETag, теперь он работает. СБОЙ
Если вы вычисляете ETag на основе подмножества полезной нагрузки, вы фактически вынуждаете пользователя не контролировать условия для небезопасного вызова без какой-либо прозрачности. PATCH преуспеет, даже если данные, связанные с этим ETag, изменились, что явно не соответствует запросам HTTP. СБОЙ

Условные запросы должны обрабатываться семантикой, подобной "Учитывая, что мой взгляд на мир по-прежнему остается прежним, затем выполните запрос. Мой взгляд на мир сделан из прошлого ответа (URI + заголовки + полезная нагрузка).