Am besten lässt sich die Funktion des RADOS-Gateways mit einem einzigen Satz beschreiben: Das RADOS-Gateway erweitert RADOS um ein ReSTful-API. Der Begriff ReSTful geistert in letzer Zeit immer häufiger durch die Welt der IT, insbesondere in Cloud-Computing-Umgebungen spielt ReST eine wichtige Rolle. Grund genug also, sich mit den Prinzipien hinter ReST einmal genauer zu befassen.

HTTP, die Triebfeder des Webs

Das Hypertext Transfer Protocol, kurz HTTP, ist das Rückgrat des Teils des Internets, der gemeinhin als World Word Web gilt. Seit der Veröffentlichung der ersten HTTP-Version (0.9) im Jahre 1991 erlebt das Protokoll einen echten Boom, der dank einer gewissen Eigendynamik im Laufe der Zeit immer noch größer wurde. Heute ist HTTP nicht mehr wegzudenken: Jeder Computer, quer über Geräte- und Betriebssystemgrenzen hinweg, hat mindestens einen HTTP-fähigen Client an Bord, einen Browser. Serverseitig ist HTTP vor allem deshalb überaus beliebt, weil es für das Protokoll zahllose Einsatzmöglichkeiten und bereits implementierte Funktionen gibt.

Hochverfügbarkeit auf Serverseite lässt sich problemlos per Fail-Over-Setup oder – und das ist die deutlich beliebtere Variante – über einen Loadbalancer realisieren. Loadbalancer gibt es diverse; sie zeichnen sich dadurch aus, dass sie für unterschiedliche Einsatzszenarien entwickelt wurden und genau diese besonders gut unterstützen. Dass HTTP im Laufe der Jahre an Beliebtheit zugenommen hat, verwundert also nicht.

Der Aufbau von HTTP ist dabei denkbar simpel. Das Protokoll ist stateless, ursprünglich war es dafür vorgesehen, dass der Client per GET-Befehl eine ganz bestimmte Seite anfordert und der Server ihm diese liefert. Der Upload war ebenso Teil des Prinzips, der PUT-Befehl legt davon Zeugnis ab. Durch die immer weiter verbreitete Nutzung des World Wide Webs entstanden aber auch so manche Begehrlichkeiten, die HTTP scheinbar an seine Grenzen brachten. Denn GET- und PUT reichen nicht, um beispielsweise Clients einen Weg zu bieten, per HTTP-Request bestimmte Aktionen auszulösen. So entwickelten sich im Laufe der Zeit verschiedene APIs, die die Limitationen umgehen: Indem ein Client bestimmte URLs aufruft und spezifische Parameter beim Aufruf mit an den Server sendet, leiten die am Server hinterlegten Dienste entsprechende Maßnahmen ein.

ReST: Standardisierte APIs

Genau hier kommt ReST ins Spiel – es handelt sich um eine Abkürzung, die für »Representational State Transfer« steht. Per Definition ist ReST gar nicht HTTP-spezifisch, doch hat es sich in den letzten Jahren insbesondere im HTTP-Umfeld durchgesetzt: Als Standard-Architektur für Web-APIs. Wichtig ist die Erkenntnis, dass ReST kein vordefinierter Standard ist. Stattdessen beschreibt der Begriff lediglich das Design einer Software, bei der Server und Client über den Aufruf bestimmter URIs standardisiert kommunizieren und bestimmte Vorgänge starten. Ein bekanntes Beispiel ist OpenStack; wie fast alle anderen Cloud-Computing-Umgebungen bietet auch in OpenStack jedem Dienst ein per HTTP ansprechbares Interface mit ReSTful-API an, das die Clients im weiteren Verlauf nutzen, um Aktionen auszulösen – so sorgt der Aufruf einer spezifischen URL samt Parametern beispielsweise dafür, dass der Server eine virtuelle Maschine startet. Auch im Bereich der Online-Speicherdienste hat ReSTful seinen Siegeszug schon begonnen: Amazons S3 bietet beispielsweise die Möglichkeit, externe Clients per ReSTful-API anzubieten. OpenStack Swift kann entweder eine eigene ReSTful-Implementation verstehen oder dank »Swift3« mit Amazon-S3-Kompatibilität aufwarten.

Das RADOS-Gateway schlägt in diese Kerbe: Es bietet eben die Möglichkeit, auf einen RADOS-Speicher per ReSTful-Protokoll zuzugreifen. Dabei versteht es wahlweise ebenfalls Amazons S3-Protokoll oder OpenStack Swift. Eine für RADOS spezifische ReSTful-Implementierung gibt es übrigens nicht, zumindest im Augenblick reichen den Ceph-Entwicklern offenbar die gegebenen Methoden.