Praktisches & Grundsätzliches zur Informatik

SOA, RAML, REST, Unverstanden, HATEOS, Roy-Fielding

REST — allzu oft noch missverstanden

So fruchtbar und genial einfach REST — ein SOA-Architektur-Konzept auch ist, wird es doch von vielen Software-Entwicklern immer noch nicht so recht verstanden — und selbst von solchen nicht, die auf diesem Gebiet forschen wie etwa die deutsche Forschungsgruppe REAL SOA Security.

Mitglieder dieser Gruppe haben sich mit einer 2015 in der Fachzeitschrift im OBJEKTspektrum abge­druckten, völlig unberechtigten Kritik an REST schon fast blamiert. Es lohnt sich, zu sehen, worin sie sich irren:

Die Autoren weisen darauf hin, dass REST häufig als Standard missverstanden wird (vergleichbar etwa mit dem HTTP Standard). Das mag sein, aber auch sie selbst trapsen in diese Denkfalle, obgleich sie sich ihrer doch — wie sie meinen — voll bewusst sind:

Betrachten wir REST also mal genauer:

Zunächst muss klar sein:


REST ist einfach nur die Idee,

jede Leistung, die ein Client vom Server erbracht sehen möchte,

so abstrakt wie nur irgend möglich zu adressieren: per URI



Das zu erreichen gelingt dort nicht so ganz, wo der Client zusammen mit dem Request auch Daten an den Server zu übermitteln hat. Beispiel: Ist die adressierte Leistung etwa eine, die das Abspeichern neuer (vom Client akquirierter) Daten verlangt, so muss der natürlich mit dem Request auch jene Daten an den Server übermitteln.

Technisch gesehen bedeutet das: Der Request muss in der Lage sein, Parameter zu haben.

Er kann nun aber durchaus solche haben, da alle Implementierungen des HTTP-Protokolls wenigstens die Silben GET und POST unterstützen.

Da man im Internet häufig Dateien (genauer: Information) hochzuladen wünscht, haben die Erfinder des HTTP-Protokolls auch ein PUT und ein DELETE vorgesehen. ABER: Und tatsächlich:

Wikipedia weist darauf hin, dass PUT und DELETE heute kaum implementiert bzw. von Webservern oft abgeschaltet sind. Das also muss berücksichtigen, wer REST-konforme APIs baut. [RAML etwa, trägt dem schon Rechnung.]


Und hier beginnt nun wirklich meine Kritik an der Auffassung der Autoren des Artikels. Sie besteht aus drei Teilen:

(1) Die Autoren schreiben, REST definiere für jede Resource einheitlich eine Schnittstelle, die aus den vier Operationen Create, Read, Update, Delete bestehe. Genau das aber ist gar nicht der Fall (und wäre darüber hinaus ja auch nur sinnvoll, wenn es ausschließlich Requests eben dieser Semantik gäbe).

Kurz: Die Autoren sehen anscheinend nur REST-Anwendungen, die Daten verwalten (und nichts sonst tun).

Sie reduzieren REST auf ( CREATE, READ, UPDATE, DELETE ) = ( PUT, GET, PUT, DELETE ), was aber grob falsch ist, denn:

Das richtig Spannende an REST ist, dass REST erlaubt, protokollunabhängig Requests JEDER NUR DENKBAREN ART abzuwickeln — und eben diese Allgemeinheit war ja das Innovative an Roy Fieldings Idee. Er schreibt wortwörtlich:


A REST API should not be dependent on any single communication protocol, ....


Das bedeutet u.A. auch: Selbst wenn das HTTP-Protokoll von unterschiedlichen Servern unterschiedlich weit implementiert ist, funktioniert REST immer noch.

Den Autoren des Artikels übersehen das, da sie offenbar nur an eine viel zu spezielle, allzu unge­schick­te Implementierung von REST denken.

(2) Sie schreiben ferner, das REST-Universum kenne noch keinen Standard für Service-Repositories und die Gestaltung von Service-Verträgen. Darauf kann man nur antworten: REST macht solche Standards überflüssig. REST will erreichen, dass jeder Server selbst festlegen kann, durch welche URI jede durch ihn abgebotene Leistung adressierbar ist. Und diese URI muss nicht immer eindeutig sein.

Es können durchaus mehrere URIs dieselbe Leistung adressieren, und es kann Teil einer Leistung kann sein, dem Client weiter URIs — für andere Leistungen — zu nennen, welche dann vielleicht auch nur im Kontext dieser einen Session Sinn machen. Diese Möglichkeit ist bekannt geworden unter dem Stichwort HATEOS.

Diesen wichtigen Punkt haben die Autoren des Artikels anscheinend überhaupt nicht begriffen.

Fakt ist: REST beseitigt — auf denkbar einfachste Weise — den mit Abstand größten Schwachpunkt des UDDI-Standards: die Notwendigkeit nämlich, dass vom Service-Katalog verlangt werden musste, jeden Service hinsichtlich all seiner einzeln aufrufbaren Funktionen und deren Parameter genau zu beschreiben.

REST entfernt diese Einschränkung, da unter REST Detailinformation zu Funktionen Schritt für Schritt vom Service selbst dem Client geliefert werden kann, womit ein UDDI dann lediglich noch erlauben muss, den Service selbst [als eine Menge von Operationen oder Subservices] zu finden: Es reicht jetzt, im Service Repository den Service eher nur qualitativ zu beschreiben.

Das geht so weit, dass — wie eben schon angedeutet — der Server den Service-Umfang nun dynamisch client-spezifisch zuschneiden kann. Eine ganze Reihe von Sicherheitsproblemen lässt sich auf diese Weise elegant und sehr effektiv lösen. Wir sehen: Die wirklichen Vorzüge von REST und HATEOS haben die Autoren des Artikels gar nicht erst erkannt.

(3) Auch was sie über angebliche Schwächen bekannter REST-Frameworks sagen, geht an Kern der Sache vorbei: Die Autoren unterscheiden nämlich nicht zwischen Der Returncode mag vom Framework und/oder vom Protokoll und seiner Implementierung beinflusst sein, die Service-Antwort aber wird niemals vom Framework abhängig sein.

FAZIT also: Was die Autoren da schreiben, ist weitgehend unverdautes Zeug. So richtig zustimmen kann man ihnen nur, wenn sie zum Schluß feststellen: Dies zeigt, dass  e r f a h r e n e  REST-Implementie­rer be­nötigt werden, um REST-Implementierungen herzustellen.


Nebenbei: Nicht nur deutsche Software-Entwickler haben REST noch nicht so ganz verstanden. Sein Erfinder — Roy Fielding — stellt auch in seiner Umgebung immer wieder fest, dass man sein Konzept recht oft zu wenig abstrakt interpretiert. Es lohnt sich zu lesen, was er schreibt.

Am Beispiel REST zeigt sich einmal mehr, dass die Fähigkeit, hinreichend abstrakt zu denken, eine der wichtigsten Eigenschaften erfolgreicher Software-Entwickler ist. Wer sie nicht besitzt, kann in diesem Geschäft stets nur Mittelmaß sein.



stw4368RESTSRREST . Service . RequestNews?

Mehr + B G E + S H A + More