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

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

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

14
etag rest

2 ответов

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

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

проверьте следующие ссылки:

9

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

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

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

с точки зрения управления параллелизмом (POST;PUT; PATCH) - импульсивно иметь ETag вычисляется на основе полезной нагрузки URI + content-type + bit-exact response. Почему?

  • если вы вычисляете ETag на основе всего объекта, надмножество полезной нагрузки ответа(т. е. ваша полезная нагрузка дает a+b, но объект на самом деле a+b+c), то выполнение патча, например, закончится неудачей, потому что ETag изменился... вы освежитесь.. вы получаете те же данные, но разные значению... вы повторяете патч с новым ETag, теперь он работает. не
  • если вы вычислите ETag на основе подмножества полезной нагрузки, которую вы фактически заставляете пользователя не контролировать условия для небезопасного вызова без какой-либо прозрачности вообще. Патч будет успешным, даже если данные, связанные с этим ETag изменились, что, очевидно, не так, как HTTP-запрос был предназначен. не

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

4