REST in Publishing

RESTful Publishing

Die Digitalisierung hat unsere Art zu kommunizieren, unsere Diskussionskultur, unsere Erwartungshaltung, sogar unser Alltagsverhaltens verhalten.

Joy Thomas Fielding hat das Akronym REST in seiner im Jahr 2000 erschienenen Dissertation „Architectural Styles and the Design of Networked-based Software Architectures“ entwickelt.Vereinfacht gesagt basiert eine REST-Architektur auf fünf Prinzipien:

* Alles ist eine Ressource
* Repräsentationen
* Statuslosigkeit
* Einsatz von Standardmethoden und Interfaces
* Hypermedia

Alles ist eine Ressource
.. und zwar mit eindeutigem (persistentem) Identifier. Eine Ressource kann ein Text sein, ein Bild, aber auch eine Sammlung, eine Liste – wie etwa ein Warenkkorb. Alle Ressourcen haben gemein, dass sie erst durch den persistent Identifier zur Ressource werden. Ein Warenkorb beispielsweise (um mit der etwas schwierigeren Vorstellung einer Liste als Ressource zu beginnen) kann bezeichnet sein mit: http://www.meinshop.de/warenkorb/87698 und die Beispielartikeln: Badeschlappen und Rettungsring umfassen.

Repräsentationen
Die Ressourcen selbst sind zwar adressierbar, auf sie wird aber eigentlich nicht selbst zugegriffen, sichtbar nach außen sind ihre Repräsentationen. Bleiben wir bei dem Beispiel unsere Warenkorbs bedeutet dies, dass die beiden Artikel beispielsweise als HTML-Seite – also als HTML-Repräsentation erscheinen können, aber auch als XML, Oder JSON oder einfach als CSV-File. Konkret kann also unser Persistent Identifier – oder besser: unsere URI – noch erweitert werden: http://www.meinshop.de/warenkorb/87698/format/xml und bei Aufruf eine XML-Repräsentation zurückliefern. Dabei soll die Beispiel-URI nicht in die Irre führen. Die Ressource bleibt eindeutig unser Warenkorb.

Statuslosigkeit
Im Beispiel unseres Warenkorbs bedeutet Statuslosigkeit das nicht gebunden sein eine Session. Der Aufruf der URI http://www.meinshop.de/warenkorb/87698 liefert eine gültige Repräsentation zurück. Jederzeit.

Einsatz von Standardmethoden und Interfaces
Dieses Prinzip ist – abstrakt beschrieben – die Forderung nach uniformen, standardisierten Bearbeitungsmechanismen. Ohne dies bereits als Implementierung zu verstehen, bedeutet dies zum Beispiel die Orientierung an den http-Verben und die Übereinkunft, dass eine Methode mit dem Namen DeleteWarenkorb(87698) die Ressource Warenkorb mit der ID: 87698 löscht.

Hypermedia
Das Hypermedia wird gerne bei der Implementierung übergangen. Dabei meint das Prinzip etwas sehr einfaches. Das Vorhandensein von Verlinkung. Unser Warenkorb könnte ja beispielsweise einen Verweis auf die Spezifikation der Badeschlappen oder des Rettungsring haben und konkret auf die Ressource http://www.meinshop.de/product/badeschlappen/details/ haben. Dieser Verweis erlaubt dem Anfragenden (und dabei ist es egal, ob es sich um einen Mensch oder eine Maschine handelt) eine Verknüpfung herzustellen zu einer weiteren Repräsentation he
Barock oder Bauhaus?
Fieldings Erkenntnisinteresse lag unverkenbar im Bereich der Software-Architektur lag. Das darf aber nicht den Blick davor verstellen, dass es sich bei REST um ein abstrahiertes Architekturmodell handelt, das so nicht nur auf eine konkrete Software-Implentierung anwenden kann. REST kann vielmehr als ein Konzept, eine Theorie veDierstanden werden. So wie wir Gebäude heute dem Barock oder Bauhaus etc. zuschreiben. REST selbst ist (mehr oder weniger) aus der Retrospektive entstanden. Dahinter steckt der Versuch die Komponenten, die zur Kommunikation im Internet gehören zu einem Kernset zusammenzufassen – um daraus allgeimngültige Aussagen über Netzwerkarchitekturen ableiten zu können.

HTTP
Eine der wichtigsten Basistechnologien des Netzes ist unbestritten das HTTP-Protokoll und so ist es nicht verwunderlich, dass die oben aufgeführten Prinzipien eng mit dem HTTP-Wortschatz verknüpft sind. Diese Zentrierung auf HTTP wird hat auch eine Folge für die Bezeichnung: REST verlässt dann etwas die Sphäre das Abstrakten und wir zu RESTful – Weswegen auch häufig der Term Restful Webservices o.ä. zu finden ist. Als Protokoll der Anwendungsschicht verfügt HTTP über eine Reihe von Verben, deren Aufruf normierte Abläufe zur Folge haben. Die bekanntesten Verben sind GET, POST, PUT & DELETE, OPTIONS, TRACE, CONNECT. GET & POST sind fest in HTML implementiert und den meisten Entwicklern bekannt. PUT & DELETE sind seltener anzutreffen, ebenso wie HEAD – was nichts über deren eigentliche Bedeutung zu sagen hat. Wenn wir uns jetzt noch einmal die Forderung nach Standardmethoden und Interfaces vor Augen führen, wird vielleicht deutlicher worauf diese Forderung abzielt – Methoden wie GetWarenkorb, DeleteWarenkorb setzen auf diesen Verben auf. Abstrakt könnte man sagen, die Verben geben vor was passiert, wenn etwas passiert.

Schon schön & jetzt?

Auch wenn die Beschäftigung mit den REST-Prinzipien schnell in Detailbetrachtungen abgleitet, steht dahinter natürlich eine ganz einfach Kernfrage: Wenn REST die Prinzipien des Internetsge entzaubert und transparent macht, was können wir für die Zukunft des digitalen Publizierens aus dieser Architektur ableiten? Oder anders formuliert: Wenn REST die Blaupause für die seit Jahrzehnten andauernde Veränderung unseres Kommunikansmechanismen ist, können wir dann erwarten, dass REST auch unsere Publikationsmechnismen verändert – sobald diese digital werden?
Meine These: Können wir.

Warum nur denkt er das?
Ganz einfach: Es macht Sinn.
Allerdings spare ich mir an dieser Stelle die Hinweise auf RESTful Webservices wie sie Amazon, HarperCollins, Springer etc. bereits umgesetzt haben. Das ist ein eigenes Kapitel und eher Ergänzung als für unsere Betrachtung essentiell.

Die Voraussetzung für etwas, das ich RESTful Publishing nennen würde. Wäre zunächst die Übereinkunft auf EIN Protokoll. Das kann HTTP sein, muss aber nicht. In der Bibliothekswelt werden gerne andere Protokoll-Stacks verwendet. Ich gehe der Einfachheit halber aber einmal davon aus, dass HTTP nicht ganz unschuldig am Erfolg des Internets ist und für unseren Anwendungsfall sich ebenso anbietet.
Wenn wir jetzt in REST denken, kramen wir die Prinzipien noch einmal heraus:

Alles ist eine Ressource.
Das trifft sich geradezu ideal. Im Grunde ist dies, was verzweifeltere Gemüter mit dem „Prinzip Buch“ oder der „Digitalen Codexform“ meinen. Das Buch ist eine Ressource, in seiner Gesamtheit. Es ist addressierbar mit einer URI, eindeutig und persistent. Denken wir uns mal eine aus:
http://www.buchdings.de/ISBN/978xxxxxxx/
Das ist unsere Ressource.

Repräsentationen
Auch ganz einfach. Das Buch kann es als HTML, XML, JSON oder doch auch als EPUB, MOBI… geben. Konkret einmal als URI: http://www.buchdings.de/ISBN/978xxxxxxx/format/EPUB
Statuslosigkeit:
Ist ebenfalls eine einfach zu erfüllende Forderung. Eine clientseitige Statusinformation benötige ich nicht.

Standardmethoden und Interfaces
Nichts spricht dagegen das bekannte SET von HTTP-Verben zu nutzen. GetBook() käme dem Aufschlagen des Buches gleich.

Hypermedia
Jetzt wird es erst richtig interessant. GetBook() müsste gar nicht das komplette Buch zurückliefern, vielleicht würden ja Verweise reichen – und zwar der Gestalt:

http://www.buchdings.de/ISBN/978xxxxxxx/Kapitel/1
http://www.buchdings.de/ISBN/978xxxxxxx/Kapitel/2
http://www.buchdings.de/ISBN/978xxxxxxx/Kapitel/3

Und in den Kapitel könnte ich tiefer einsteigen:

http://www.buchdings.de/ISBN/978xxxxxxx/Kapitel/3/Absatz/1
http://www.buchdings.de/ISBN/978xxxxxxx/Kapitel/3/Absatz/1/wort/3
http://www.buchdings.de/ISBN/978xxxxxxx/Kapitel/3/Absatz/1/wort/3/bis/4
Das wäre ziemlich RESTful.
Und was haben wir davon, sollten wir das wirklich in Erwägung ziehen?
Zum Beispiel eine nachhaltige Möglichkeit das wissenschaftliches Arbeiten auch in Zukunft möglich zu machen. Was wären die Humanities ohne die Kulturtechnik des Zitatnachweises?

Vor allem aber befördert REST das Denken in vernetzten Prozessen. Die Auslieferung unserer Verlagsinhalte in Content-Containern wie wir sie heute kennen ist sicher charmant, allerdings ebenso eine dieser vielbeschworenen Brückentechnologien wie es gleichzeitig Bücher nicht zwigend nur in Browsern geben wird. RESTful Publishing bedeutet digitale Publikationsprozesse ohne medienbrüche zu realisieren. Im besten Fall gelingt es uns mit RESTful Publishing ein Literaturnetz aufzubauen, dass sich nahtlos und barrierefrei in digitale Kommunikationskonzepte integrieren und modularisieren lässt.
Wir sollten darüber diskutieren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.