[Research] HTML5’s Client-Side Storage Mechanism

Image Credit

之前一直在研究 Chrome Extension,而其中頻繁地使用了 HTML 的 Client-Side Storage Mechanism,所以就花了一些時間去 survey 了一下資料並整理如下:

一開始我想要先了解一下為什麼有了 Cookie 的存在,卻又還要在 HTML specification 中提出新的機制來儲存資料?而根據 Wiki 的資料 顯示,Cookie 雖然只是一個純文字的文件檔,但其實在 Browser 與 Server 做溝通時,都會被附加在 HTTP Header 的 Cookie 欄位,這就是為什麼 Cookie 的資料在前後端都可以被存儲的原因。

就在我了解了其存在的意義後,我就想要了解為什麼都已經存在著 Cookie 這樣的存取機制,卻還要在 HTML5 的 Specification 中提出新的存取機制?這是一個好問題,在看了 Stack Overflow 的討論文之後得到了答案。

有的時候,我們並不需要與 Server 做太多的互動,只是需要一個前端可以互相使用的存取機制就好,哪怕只是傳遞一些簡單的識別代號。因為有了這樣子的需求,那 Cookie 在某種程度上來說就太大材小用了,甚至可以說是過於痴肥。所以在做了這樣的理解之後,就可以合理的推測前端「輕量級的存取機制」之必要性。(時間點就沒有考究了)

那在 HTML5 的 Specification 中到底提到了什麼樣子的新型存取機制?原本可以歸類為下面三類:

  1. Session Storage
  2. Local Storage
  3. Database Storage

之所以會說「原本」是因為 Database Storage 不知道因為什麼緣故就停止維護了(參閱下圖),所以我們就在此不做深入討論,只討論 Session 和 Local Storage。

如果要快速地了解兩者的差異,就是自己動手玩看看

接下來還是要說明一下:Session 的中文是叫「會期」,就是一段會議、對話的期間,而在 HTML5 下,如果我們採用 Session Storage ,則我們資料的生命週期(Persistence)及生存範圍(Scope)都只能在一個 tab / window 下。說實在的,一時真的想不到該機制能應用在什麼樣的情況下,但 W3C 有提到一個有趣的情況,就是當一個使用者在進行拍賣的交易的時,雙開了兩個同樣帳號的 tab 來做購買的動作(接下來是我個人的情境補完),如果我們是利用 cookie 來紀錄欲購買商品的編號,那其實就很有可能因為兩個 tab 存取相同的 cookie 檔(沒有 lock)而造成交易上的異常。所以在這種時候 Session Storage 就相當適用。

而另外一個 Local Storage 和 Session Storage 的差異就在於 Persistence 和 Scope ,它是一個可以長時間儲存的機制,即使是在關閉 tab / window 之後,先前所儲存的資料依然保留著,而範圍就是所有的 tab / window 都能夠存取使用,除此之外,還能夠允許同個 domain 間的資料互相存取,因此在資料的傳遞上面佔有很大的優勢。以我自己為例,我在 Google Chrome Extension 的開發時,就大量應用到 Local Storage 來幫助我的外掛記錄使用者的偏好設定,以便於在各個子腳本中做資訊的傳遞。

以上就是這次 Client-Side Storage Mechanism 的研究,歡迎留言指教 :]