所以我已經閱讀了一些關於在RESTfull API中使用Etags的文章，其中絕大多數人說Etag頭文件應該是資源/實體/對象的散列，接縫浪費。RESTfull API中使用的Etags通常被描述爲散列
使用散列：請求來了一個給定的Etag，資源需要被提取（通常從數據庫），然後它需要使用MD5/SHA /任何散列和結果與Etag比較，這需要時間和CPU。
Etag可作爲行的另一列（與任何正常行更新並行更新）存儲在數據庫中，因此無需爲每個請求計算它，然後在SELECT查詢中您可以通過WHERE實體.etag == ETAG。這意味着Etag必須從數據庫和客戶端帶外生成到數據庫，這是有點限制的。
如果您要將它存儲在數據庫中，那麼您最好使用上次更新的時間，這是一個本地數據庫函數（nornally），不需要額外的處理（哈希）。
爲什麼建議使用散列？
時間戳是不可靠的Etags，因爲兩個不同的更新可能以相同的時間戳到達數據庫。客戶端可能會獲得版本1，並且以後會錯過版本2，因爲它具有相同的Etag。
加密散列效果更好，因爲每個不同的更新都會有不同的散列值。作爲獎勵，相同的更新將具有相同的散列。
雖然沒有必要對內容進行哈希處理，但任何唯一的標識符都可以。許多系統都會爲每次更新生成一個唯一的ID，並且該ID將成爲Etag。
認爲唯一/隨機ID足夠好 – Metalstorm
DB生成的唯一ID就足夠了。密碼隨機ID也足夠好（有些人使用uuidgen，這很好）。蹩腳的隨機ID不是。 –
建議使用散列，因爲ETag在底層資源發生變化時應該有機會。歷史上，哈希是實際內容的表示，所以它是解決這個問題的簡單方法。
您可以通過使用資源緩存散列來減輕散列成本。
唯一ID的想法是有效的，而不是主鍵。每次資源發生變化時，ETag都需要更改，而主鍵不會。但是哈希的好處在於，如果將資源更改爲某種內容，然後將其改回（即撤消更改），哈希將（通常）恢復到原來的狀態，因此任何「錯過」干預改變，將不會看到它（因爲它們的舊ETag仍然有效）。
時間戳適用於緩慢變化的資源。時間戳可以是相當高的分辨率。但它在ETag方面與內容本身沒有實際聯繫的同樣問題與唯一生成的ID相同。
有問題藏在這裏某處，還是你只是想和我們分享你的想法？ – Chris
etag的最初目的是通過在資源被再次請求並且沒有改變時返回304來確保安全帶寬。它並不打算在服務器上節省處理時間。一個聰明的實現也可以做到這一點，但對於原始計劃，散列是一個不錯的選擇。 –
@Klaus D這是可以理解的，但是當有更好的（？）替代散列時，通過使用散列節省帶寬來增加處理時間/資源消耗似乎不合邏輯？我猜測哈希會解決有點奇怪的參數，如果客戶端正在更新具有相同/不變值的資源，導致上次更新時間發生變化，則會使所有Etags無效。 – Metalstorm