Businessdaten raus aus der Session

Früher oder später stolpert in jedem Web-Projekt das Entwicklerteam über das Thema „Sessions“. Hier entbrennen nicht selten erbitterte Diskussionen zwischen dem üblicherweise großem Lager der Session-Befürworter und einzelnen REST -Evangelisten, die darin enden, dass man sich in der Regel für Sessions entscheidet.

Die Gründe dafür sind unterschiedlich:

• Es wurde demokratisch entschieden.
• Man orientiert sich an anderen Projekten des Unternehmens.
• Sessions sind bereits weit verbreitet und werden von allen gängigen Frameworks unterstützt.
• Es wurde noch niemand dafür gefeuert, weil er sich für Sessions entschieden hat.

Ursachenforschung

Die ganze Situation hat ihren Ursprung in der Tatsache, dass das HTTP-Protokoll zustandslos ist und eigentlich keine Beziehung zwischen zwei Aufrufen eines Benutzers erkennt. Mehrseitige Formulare und Warenkörbe, die sich während des Stöberns füllen sollen, erscheinen dann unmöglich.

Sessions lösen dieses Problem, in dem sie der „Sitzung“ eine Identifikationsnummer (SessionID) vergeben, und alle wichtigen Daten für den aktuellen Vorgang über mehrere Browseranfragen hinweg serverseitig speichern.

REST hingegen fordert eine Rückbesinnung auf das zustandslose HTTP. Alle für eine Anfrage notwendigen Daten sollen über den HTTP Aufruf kommen. – Wie auf diese Weise Web-Shops funktionieren sollen, erschließt sich nicht auf Anhieb.

Daher würde ich hier gerne einen Versuch wagen, der einerseits einen Kompromiss zwischen Sessions und REST bildet und gleichzeitig einen Ausblick auf potentiellen Mehrwert geben.

Nur REST?

Folgt man der Forderung von REST vollständig, so bedeutet dies auch einen Verzicht auf Cookies. Eine Authentifizierung ist dann nur über das http sinnvoll, aber auch unbequem. Zwar merkt sich der Browser den Benutzernamen und das Passwort, aber bei jedem Öffnen der Webseite erscheint eine Passwortabfrage.

Cookies für die Authentifizierung

Meines Erachtens sind Cookies ein durchaus probates und wirkungsvolles Mittel um eine erfolgreiche Authentifizierung eines Benutzers über die Sitzung hinweg zu speichern. Die Verwaltung der Cookies in Browsern ist in der Regel recht einfach und bleibt (wenn gewünscht) auch über mehrere Tage hinweg gespeichert.

Ein wenig mehr REST bitte

Eigentlich hat man jetzt de facto Sessions eingeführt, da man dem Benutzer doch wieder ein Identifikationsmerkmal im Browser unterjubelt. Viele Entwickler machen hier eine gedankliche Unterscheidung nach dem Verwendungszweck. Der Login und der Warenkorb sind einfach unterschiedliche Teile der Anwendung, auch wenn diese beide die gleiche Session nutzen würden.

Hier fordere ich nun, dass die Sitzungsdaten, wie z.B. der Warenkorb eines Web-Shops, nicht in der Session gespeichert werden. Und das obwohl jetzt die Hürde eigentlich am geringsten ist. Vielmehr sollte die bereits vorhandene Bestelldatenbank genutzt werden. Dafür gibt es gute Gründe.

An dieser Stelle hört man üblicherweise viele Aufschreie entsetzter Entwickler: „Aber die Bestellung ist doch noch gar nicht abgeschickt! Was wenn der Kunde den Vorgang abbricht oder gar den Browser einfach schließt?“

Was passiert denn mit einem Warenkorb, wenn er in der Session gespeichert wird? Diese Daten sind für das System unsichtbar bis der Kunde die Bestellung aufgibt. Schließt er den Vorgang nicht ab, wird die Session nach Ablauf einer gewissen Frist gelöscht. Die Vorteile sind also:

• Nur vollständige Bestellungen landen im System.
• Abgebrochene Bestellungen werden automatisch bereinigt.

Was aber, wenn die Daten gleich in der Datenbank gespeichert werden und die Bestellung als noch nicht „beauftragt“ markiert wird? Es ergeben sich weitere Vorteile:

• Bestellungen können (wenn gewünscht) nach Tagen wieder aufgenommen werden.
• Auch nicht beauftragte Zusammenstellungen von Waren sind eine nutzbare Datengrundlage für den Verkäufer.
• Daten liegen bereits in der bekannten strukturierten Form vor und lassen sich so ähnlich gut auswerten.
• Wieso einige Käufer ihre Bestellung abbrechen, lässt sich so eventuell eher ermitteln, als wenn diese Daten gar nicht erst erfasst werden.

Sessions sollen einen Zustand erfassen. Aber nicht alle Zustandsdaten sind temporär. Meine unvollständige Bestellung z.B. spiegelt meinen Geschmack wieder, der auch nächste Woche noch ähnlich sein wird. Selbst temporäre Daten sind in einer strukturierten Datenbank besser aufgehoben und somit wertvolle nutzbare Information.

Und komme ich nächste Woche wieder in den Web-Shop bietet er mir evtl. den teuren Plasmafernseher als Finanzierungsangebot an.