Modellierung von Hypermedia bei REST mit endlichen Automaten

Die einschlägige Literatur zur Programmierung von REST API, vernachlässigt eine ausführliche Diskussion der Hypermedia Idee von REST. Typischerweise werden in diesen Büchern die Themen Ressourcen, Repräsentationsformate, Media-Typen, HTTP Verben behandelt, wenn es um das Design einer Rest-API geht. Natürlich wird auch über die verschiedenen Möglichkeiten gesprochen, eine Uri aufzubauen. Zu den eher technischen Themen gehören dann zum Beispiel Fragen der Sicherheit oder der Implementierung mit Hilfe von speziellen Frameworks.

Eine zentrale Idee einer REST API ist jedoch das Konzept von Anwendungszuständen. Eine Anwendung kann man sich vorstellen wie einen endlichen Automaten. Der Nutzer der Anwendung befindet sich zu jedem Zeitpunkt in genau einem Anwendungszustand. Durch Bedienung der Applikation erfolgt ein Zustandswechsel. Am einfachsten macht man sich dieses Modell eines endlichen Automaten bei Webseiten klar. Der Nutzer gibt die Adresse einer Webseite in den Browser ein und erhält damit die Homepage der Web Anwendung. Diese Homepage entspricht dem Initialzustand des endlichen Automaten. Drückt der Nutzer nun ein Link, löst er damit einen Zustandsübergang oder anders gesagt eine Transition aus. Das Ziel des Links ist eine weitere Webseite, die dann einen neuen Zustand darstellt. Meist kann der Nutzer in einer Web Anwendung stets zu der Seite zurückkehren von der er die aktuelle Seite erreicht hat. Dies bedeutet jedoch lediglich, das in dem Modell des endlichen Automaten jeder Zustandsübergang bidirektional ist. Was hier am Beispiel von Webanwendungen erklärt wurde, gilt in ähnlicher Form auch für Desktop Applikation und für mobile Applikationen.

Schauen wir uns das Beispiel der mobilen Applikationen zunächst an. Eine mobile Applikationen besteht typischerweise aus einer Menge von einzelnen Bildschirmen. Der Nutzer navigiert von Bildschirm zu Bildschirm über das Drücken von Buttons oder die Auswahl von Datenelementen. Es existiert ebenfalls eine Art des Back Button. Bei manchen Geräten ist hierfür sogar ein eigener Knopf reserviert. Bei iPhones wird diese Funktionalität über einen Button in der linken oberen Ecke realisiert. Jeden einzelnen Bildschirm können wir nun als einen Zustand der Applikation ansehen. Der Wechsel zwischen den Bildschirmen entspricht den Transitionen.

Dieses Denken in einem Modell eines endlichen Automaten ist jedoch scheinbar selbst in der Welt der Webapplikationen nicht mehr gebräuchlich. Die Ursache hierfür ist technischer Natur. Eine Web Applikation besteht heutzutage eben nicht mehr aus einer Folge von einzelnen statischen HTML Seiten, sondern im Extremfall nur noch aus einer einzelnen Webseite die auch nur das Gerüst zur Darstellung von Inhalten in einem Browser liefert. Das konkrete Aussehen der Webseite bzw. sein Inhalt wird über Javascript definiert und unter Umständen ohne Neuladen von Webseiten auch verändert. In einem solchen Ansatz lassen sich einzelne Zustände der Webapplikation nur noch schwer identifizieren. Trotzdem bleibt es richtig, dass es auch in solchen Applikationen einzelne getrennt voneinander zu sehende Zustände gibt.

Bezogen auf die Entwicklung von REST APIs, scheint es also geboten zu sein, früher und stärker Ideen der endlichen Automaten aufzunehmen. Mir scheint, dass dieser Entwicklungsschritt, an dessen Ende ein Zustandsübergangsdiagramm steht, sogar noch vor der Definition von Ressourcen oder Modellen stehen sollte. Man sollte sich stets klarmachen, dass in einer REST Applikation der Server den vollständigen Fluss durch die Applikation definiert. Eine REST API ist kein generisches Interface durch das dem Entwickler eines Clients, zum Beispiel einer mobilen Applikationen, ein hoher Freiheitsgrad übergeben wird. Im Gegenteil: der Entwickler wird sehr stark eingeschränkt, und wird etwas übertrieben gesprochen auf die Programmierung der grafischen Benutzeroberfläche beschränkt.