HTML5: Einführung in die Web Storage API - LocalStorage & SessionStorage
Die HTML5 Web Storage API, teilweise auch als DOM Storage bezeichnet, dient der clientseitigen Speicherung von Daten in Form von Schlüssel-Wert-Paaren. Man kann auch vereinfacht sagen, die Daten werden lokal im Webbrowser gespeichert.
Grundsätzlich ist die Web Storage API in die zwei verschiedenen Speicherarten namens LocalStorage und SessionStorage unterteilt.
In diesem Beitrag stelle ich euch nun die HTML5 Web Storage API vor.
LocalStorage vs. SessionStorage
LocalStorage dient zur dauerhaften Speicherung von langlebigen Daten. Wohingegen SessionStorage das temporäre Speichern von sitzungsbezogenen und kurzlebigen Daten ermöglicht. Infolgedessen unterscheiden sich beide Speicherarten bzgl. Gültigkeitsdauer und Gültigkeitsbereich:
LocalStorage | SessionStorage | |
---|---|---|
Gültigkeitsdauer | Daten bleiben sowohl nach Schließen des Webbrowser-Fensters bzw. Tabs als auch nach Schließen des Webbrowsers erhalten. | Daten bleiben nur solange erhalten bis das Fenster bzw. der Tab des Webbrowsers, in dessen Kontext die Daten gespeichert wurden, geschlossen wird. |
Gültigkeitsbereich | Daten sind unabhängig vom Webbrowser-Fenster bzw. Tab verfügbar. | Daten sind nur in dem Webbrowser-Fenster bzw. Tab verfügbar, in dessen Kontext die Daten gespeichert wurden. |
Im Zusammenhang mit dem Gültigkeitsbereich sei noch erwähnt, dass die Web Storage API der Same Origin Policy (SOP) unterliegt. Konkret bedeutet das, dass eine Webseite mit der Herkunft (Origin) http://www.abc.de:80
keinen Zugriff auf die mittels der Web Storage API gespeicherten Daten einer Webseite mit der Herkunft http://www.xyz.de:80
hat.
Die Web Storage API im Detail
Die synchrone Web Storage API setzt sich zum einen aus dem Storage
- und zum anderen aus dem StorageEvent
-Interface zusammen. Der eigentliche Zugriff auf den jeweiligen Speicher erfolgt über das globale localStorage
bzw. sessionStorage
-Objekt, die das Storage
-Interface gleichermaßen implementieren.
Das Storage
-Interface ist dabei wie folgt definiert:
Sowohl für die Schlüssel als auch die einzelnen Werte sind nur Daten vom Typ DOMString
zulässig. Wenn ihr also Arrays oder Objekte speichern wollt, müsst ihr diese erst in einen String konvertieren.
Die Spezifikation der Web Storage API gibt vor, dass Webbrowser den verfügbaren Speicher aus Sicherheitsgründen begrenzen sollen. Das Speicherlimit kann dabei je Webbrowser unterschiedlich sein.
In der folgenden Tabelle sind die einzelnen Attribute bzw. Funktionen kurz erläutert:
Attribut / Methode | Beschreibung |
---|---|
length | Gibt die Anzahl der Schlüssel-Wert-Paare zurück. |
key(index) | Gibt den Schlüssel an der Position index zurück. |
getItem(key) | Gibt den Wert für den Schlüssel key zurück. |
setItem(key, value) | Speichert den Wert value für den Schlüssel key . |
removeItem(key) | Löscht den mit dem Schlüssel key assoziierten Wert. |
clear() | Löscht alle Schlüssel-Wert-Paare. |
Bei der setItem
-Funktion ist es so, dass zuallererst geprüft wird, ob der angegebene Schlüssel bereits existiert. Falls dem nicht so ist, wird der Schlüssel erzeugt und der angegebene Wert gespeichert. Für den Fall, dass der Schlüssel bereits existiert, wird der alte mit dem neuen Wert überschrieben. Weiterhin ist es bei der removeItem
-Funktion so, dass neben dem Wert auch der Schlüssel selbst gelöscht wird.
Neben dem eigentlichen Storage
-Interface gibt es, wie bereits erwähnt, zusätzlich noch das StorageEvent
-Interface. Ein StorageEvent
wird ausgelöst, sobald im Speicher eine Änderung registriert wurde. Dadurch besteht die Möglichkeit Race Conditions entgegenzuwirken, indem bei Eintritt eines solchen Events die Daten synchronisiert werden können. Hierfür liefert das entsprechende StorageEvent
-Objekt sowohl den Schlüssel als auch den alten sowie neuen Wert des geänderten Schlüssel-Wert-Paares mit.
Die Web Storage API in Aktion
Dank der Einfachheit der Web Storage API benötigen wir nur eine einzelne Zeile Code, um ein Schlüssel-Wert-Paar zu speichern:
Da es sich bei dem localStorage
-Objekt um ein JavaScript-Objekt handelt, können wir auch folgendermaßen Daten speichern:
Analog zum Speichern können wir genauso einfach die Daten wieder auslesen:
Einen einzelnen Datensatz können wir mittels der removeItem
-Funktion löschen:
Webbrowser-Unterstützung
Die Web Storage API wird in allen gängigen Webbrowsern unterstützt. Eine genaue Auflistung der einzelnen Webbrowser und den jeweiligen Versionen findet ihr auf caniuse.com.
Vor- & Nachteile
Wie jede API bzw. Technik hat natürlich auch die Web Storage API gewisse Vor- als auch Nachteile:
Vorteile:
- einfach zu implementierende API
- einfache Struktur der Daten durch Schlüssel-Wert-Format
- von allen modernen Webbrowsern unterstützt
- bietet mehr Speicher als Cookies
Nachteile:
- synchrone API blockiert UI-Thread bei jedem Lese- und Schreibvorgang
- keine asynchrone Variante der API vorhanden
- nicht innerhalb von Worker-Threads nutzbar
- keine Unterstützung von Transaktionen (wie bei Datenbanksystemen)
- Speicherlimit mit ca. 5MB relativ gering bemessen
- nur
DOMString
als Datentyp unterstützt - kein Mechanismus zum Durchsuchen der Daten
Mögliche Anwendungsfälle
Im Folgenden einige mögliche Anwendungsfälle für den Einsatz der Web Storage API:
- Status der GUI einer Webseite bzw. Webapplikation speichern
- Spielstatus bei Spielen speichern
- anwendungs- & benutzerspezifische Einstellungen speichern
- Web-Service-Anfragen bzw. die erhaltenen Daten cachen, da speziell Web-Services oftmals nur eine begrenzte Anzahl an Zugriffen in einem bestimmten Zeitintervall erlauben
- generell zum Cachen von Daten, um z.B. Netzwerktraffic einzusparen und Performance einer Webapplikation zu verbessern
Fazit
Die HTML5 Web Storage API eignet sich, wie ich finde hervorragend zum Speichern von Daten kleinerer Größe. Habt ihr also Daten, die nicht notwendigerweise auf dem Server gespeichert werden müssen, wäre Web Storage eine sinnvolle Möglichkeit die Daten clientseitig zu speichern.
Was ich wünschenswert fände, wäre eine asynchrone API-Variante, wobei die API dann wohl wieder komplexer geworden werden.
- 5. Mai 2013
ursprüngliche Veröffentlichung in meinem ehemaligen Blog "Smart-Webentwicklung"