所以我已经阅读了一些关于在RESTfull API中使用Etags的文章，其中绝大多数都说Etag标题应该是资源/实体/对象的哈希值，这样会造成浪费。
使用散列：请求带有给定的Etag，需要获取资源（通常来自数据库）然后需要使用MD5 / SHA /其他方式进行散列，并将结果与Etag进行比较，这需要时间和CPU。
Etag可以作为行的另一列存储在数据库中（与任何正常的行更新一起更新），因此不必为每个请求计算它，然后在SELECT查询中可以通过WHERE过滤entity.etag == ETAG。这意味着Etag必须从数据库和客户端到数据库的带外生成，这有点限制。
如果您将它存储在数据库中，那么您也可以使用上次更新的时间，这是一个本机数据库功能（nornally）并且不需要额外的处理（散列）。
为什么建议使用哈希？
答案 0 :(得分：0)
时间戳不是可靠的Etags，因为两个不同的更新可以使用相同的时间戳到达数据库。客户端可以获得版本1，后来因为它具有相同的Etag而错过版本2。
加密哈希值更好，因为每个不同的更新都会有不同的哈希值。作为奖励，相同的更新将具有相同的散列。
但是，并不需要对内容进行哈希处理 - 任何唯一标识符都可以。许多系统都让数据库为每次更新生成一个唯一的ID，这个ID将成为Etag。
答案 1 :(得分：0)
建议使用哈希，因为当底层资源发生变化时，ETag应该有机会。从历史上看，哈希是实际内容的表示，因此它是解决问题的简单方法。
您可以通过使用资源缓存哈希来降低散列的成本。
唯一ID的概念是有效的，而不是主键。每次资源更改时ETag都需要更改，而主键不会更改。但哈希的优点在于，如果你将资源更改为某个东西，然后将其更改回来（即撤消更改），哈希将（通常）恢复到原来的状态，所以任何＆＃34;错过＆ ＃34;干预变化，实际上看不到它（因为他们的老ETag仍然有效）。
时间戳对缓慢变化的资源有效。时间戳可以是相当高的分辨率。但是，就ETag而言，与内容本身没有实际联系的唯一生成ID同样存在问题。