Этаги, используемые в RESTfull API, обычно описываются как хэши
Итак, я прочитал несколько статей об использовании Etags в API-интерфейсах RESTfull, и подавляющее большинство из них говорят, что заголовок Etag должен быть хешем ресурса / сущности / объекта, это выглядит расточительно.
Использование хэша: запрос приходит с данным Etag, ресурс должен быть извлечен (обычно из базы данных), затем он должен быть хеширован, используя MD5/SHA/ что угодно, и результат по сравнению с Etag, это требует времени и ЦП.,
Etag может храниться в базе данных как другой столбец строки (обновляется вместе с обычным обновлением строки), чтобы его не нужно было вычислять для каждого запроса, тогда в запросе SELECT вы можете фильтровать по WHERE entity.etag== ETag. Это означает, что Etag должен быть сгенерирован вне базы данных от базы данных и от клиента до базы данных, что немного ограничивает.
Если вы храните его в базе данных, тогда вы можете просто использовать последнее обновленное время, которое является естественным функционалом базы данных (обычно) и не требует дополнительной обработки (хеширования).
Почему предлагается использовать хеши?
2 ответа
Предлагаются хэши, потому что ETag должен быть случайным, когда основной ресурс изменяется. Исторически хэши являются отображением реального содержимого, поэтому это простое решение проблемы.
Вы можете уменьшить стоимость хеширования, кэшируя хеш с ресурсом.
Идея уникального идентификатора верна, но не первичный ключ. ETag должен меняться каждый раз, когда изменяется ресурс, первичный ключ - нет. Но хорошая природа хэша заключается в том, что если вы измените ресурс на что-то, а затем вернете его обратно (то есть отмените изменение), хеш (как правило) вернется к тому, что было, так что все, что "пропустило" вмешательство изменение, фактически не увидит его (так как их старый ETag все еще действителен).
Отметка времени действительна для медленно меняющихся ресурсов. Отметки времени могут быть довольно высокого разрешения. Но он так же страдает от той же проблемы, что и уникальный сгенерированный идентификатор с точки зрения того, что ETag не имеет реальной связи с самим контентом.
Метки времени не являются надежными Etags, потому что два разных обновления могут попасть в базу данных с одной и той же отметкой времени. Клиент мог получить версию 1, а позже пропустить версию 2, потому что у него был тот же Etag.
Криптографические хеши лучше, потому что каждое новое обновление будет иметь разный хеш. В качестве бонуса идентичные обновления будут иметь одинаковый хэш.
Однако не обязательно хешировать содержимое - подойдет любой уникальный идентификатор. Во многих системах база данных генерирует уникальный идентификатор для каждого обновления, и этот идентификатор становится Etag.