HTTP слабый пример Etag,

Question

Я пытался понять HTTP Etags и придумал пример использования. Правильно ли я думаю?

Допустим, у нас есть API RESTful с пользовательскими типами ссылок. Некоторые ресурс возвращает набор XML-данных с помощью ссылки, как это:

< ссылка отн = "HTTP: //my.api/relation_definition" URL = "HTTP: //my.api/resources/someId"/>

Обратите внимание на пользовательское определение rel, которое приводит к некоторому описанию значения этой ссылки.

Теперь, если это описание rel даст слабый Etag. Программисты, которые создают клиент для моего REST api, могут встроить этот etag в своего клиента. Поскольку пользовательское отношение может означать какое-то особое поведение клиентского приложения. Теперь клиентское приложение может проверить, имеет ли ссылка определение: nt изменено путем запроса с помощью этого слабого etag. Если это то же самое, все в порядке. Если слабый etag изменился, это означало бы, что клиенту, возможно, придется изменить/пересмотреть его поведение на этих ссылках и, возможно, уведомить его разработчика о принятии некоторых действий.

Я использую слабые etags вместо сильных, потому что я, как поставщик api, чаще меняю описание ссылки, исправляю опечатки, добавляю несколько примеров и т. Д., Которые не меняют смысла. Поэтому я бы изменил слабый etag описания только в том случае, если значение этих ссылок изменилось.

Правильно ли я понимаю цель слабых etags?

Answer 1

Самое главное понять, что изменение ETag, будь то слабый или сильный, заставит браузер запрашивать актив заново. Единственное различие заключается в том, насколько браузер доверяет ETag, когда вы НЕ меняете его.

Для вашего случая использования «некоторого описания смысла этой ссылки» это звучит так, будто вы говорите о небольшом документе со статическим (или почти статическим) контентом, поэтому не имеет значения, является ли ваш ETag отмечены как слабые или сильные, потому что браузер, вероятно, не собирается делать ничего особенного, что может выиграть от гарантий сильного ETag. Клиенты API, вероятно, вообще не заботятся о слабых и сильных ETags.

Где сильные ETags вступают в игру - для больших загрузок (программное обеспечение, видео, аудио и т. Д.), Где браузер может использовать запросы диапазона для загрузки только части актива. Сильный ETag означает, что элемент байта для байта идентичен, поэтому можно использовать куски файла, который был загружен ранее. Например, представьте себе возобновление большой загрузки, которую вы начали на прошлой неделе. Если ETag был тем же, но он был слабым, браузер мог бы решить загрузить весь файл, тогда как сильный ETag может привести к возобновлению существующей загрузки.

Опять же, для вашего случая, даже не беспокойтесь об этом. Если вы используете хэш файла, вам гарантируется «байт-байт-идентичная» семантика, поэтому продолжайте и назовите его сильным, но в любом случае вы должны работать одинаково для вас. Опять же, клиенты API, вероятно, вообще не заботятся о слабых и сильных ETags.

Что касается того, когда вы должны изменить ETag, если вы не делаете 100 изменений в день, продолжайте и меняйте его каждый раз, когда вы делаете изменения.