© DrHitch/Shutterstock.com
REST

1 Grundlagen von REST und HTTP


REST ist in aller Munde. REST ist jedoch nicht gleich REST. Es kommt darauf an, wie es angewendet wird. Dazu wurde sogar ein REST-Reifegradmodell mit aufeinander aufbauenden Stufen definiert, das beschreibt, auf welche Arten REST angewendet werden kann, wobei die höchste Stufe die bestmögliche Implementierung von REST darstellt, zumindest aus akademischer Sicht. Das erste Kapitel führt Sie in die Grundlagen von REST ein, beginnend beim HTTP-Protokoll.

REST an sich ist zunächst nichts völlig Neues. Ganz vereinfacht gesagt könnte man behaupten, REST ist nichts anderes als HTTP und damit so alt wie das Internet selbst. Heute wird REST sehr oft in der Kommunikation zwischen verschiedenen Anwendungen genutzt – ein Thema, das noch vor einigen Jahren stark durch SOAP und Web Services abgedeckt wurde, und noch länger vorher durch Technologien wie COM/DCOM bzw. CORBA oder durch das .NET-Remoting-System innerhalb von .NET Framework.

Microsoft hat sowohl COM/DCOM als auch .NET Remoting entwickelt, um Anwendungen die Kommunikation über Prozess- und auch Rechnergrenzen hinweg zu ermöglichen. Die Technologie war jedoch sehr stark proprietär und fand somit außerhalb von Microsoft-Produkten kaum Verbreitung. Der nächste große Schritt hin zu einer plattformunabhängigen Technologie zur Kommunikation zwischen Anwendungen wurde mit Web Services und SOAP gemacht. Web Services setzen dabei genau wie REST auf HTTP als Protokoll zum Transport der Daten und auf SOAP, um die Nutzdaten innerhalb des HTTP-Protokolls zu „verpacken“.

Dabei war SOAP zunächst sehr erfolgreich; mit dem Siegeszug von Smartphones, Smartwatches und Co. wurden jedoch Schwächen in der Technologie erkannt. Dazu zählen vor allem das aufwendige „verpacken“ und „entpacken“ der Daten in das SOAP-Protokoll, also die Serialisierung und Deserialisierung. Da SOAP als typsicher konzipiert wurde, mussten mit den Nutzdaten viele Metadaten übertragen werden, um die Typsicherheit gewähren zu können. Das blähte SOAP-Nachrichten zusätzlich auf. Aus den beiden genannten Gründen war es sehr schwierig, SOAP einwandfrei auf Smartphones zu verwenden. Die aufwendige Serialisierung und Deserialisierung kostete sehr viel Prozessorleistung und damit Strom, was negative Auswirkungen auf die Akkulaufzeit der Geräte hatte. Die Metadaten blähten die Nutzdaten dermaßen auf, dass sich die gesamte Größe einer zu übertragenden Nachricht im Vergleich zur Größe der Nutzdaten gut und gerne verdoppeln und verdreifachen konnte. Aufgrund der limitierten Bandbreite bei Mobilgeräten dauerte die Kommunikation damit länger und beanspruchte zu viel Datenvolumen. Mit REST hat man eine Lösung gefunden, die die Kommunikation stark vereinfacht und es ermöglicht, beinahe vollständig auf Metadaten zu verzichten.

Die Idee hinter REST

REST steht für Representational State Transfer und wird in der Regel in Szenarien der Maschine-zu-Maschine-Kommunikation verwendet. Dabei ist REST, anders als zum Beispiel TCP oder HTTP, an sich zunächst kein Protokoll. Es definiert bzw. spezifiziert keine Datenformate, Nachrichtenformate oder Ähnliches. Es ist eher als Programmierparadigma zu verstehen. Als ein solches Paradigma beschreibt es Denkweisen und Vorgehen, die uns bei der Lösung von wiederkehrenden Problemen in der Kommunikation zwischen Systemkomponenten helfen sollen. Manche gehen sogar so weit und behaupten, REST sei ein Architekturstil für gesamte Anwendungssysteme.

Das wichtigste Unterscheidungsmerkmal von REST zu SOAP ist die Ressourcenorientierung. In der dienstorientierten (SOA: Service-oriented Architecture) Welt von Web Services mit SOAP hat man seine Kommunikationsschnittstelle über Dienste mit Methoden verfügbar gemacht. Diese nehmen Objekte entgegen und geben solche zurück. Jeder Dienst mit all seinen Methoden ist dabei unter genau einer Adresse erreichbar. Die Information, welche Methode auf einem Dienst aufgerufen werden soll, ist in den Metadaten einer Nachricht enthalten, die man zu einem Dienst sendet.

Bei REST existieren keine Dienste und Methoden mehr. Man spricht hier nur noch von Ressourcen. Ressourcen sind die Daten, die während der Kommunikation angesprochen werden. Eine Ressource kann daher immer über eine eindeutige Adresse adressiert werden. Die Adresse fungiert somit als eine Art Zeiger auf ganz bestimmte Daten eines Systems. Die Dokumentation einer REST-Schnittstelle zu einer Anwendung besteht daher in der Regel immer aus einer Liste von Adressen mit einer Beschreibung, wel...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang