Was ist eine REST-API?

Das REST- oder RESTful-API-Design (REST steht für Representational State Transfer) nutzt die Vorteile bestehender Protokolle. Während REST über nahezu jedes beliebige Protokoll verwendet werden kann, wird in Verbindung mit Web-APIs in der Regel HTTP genutzt. Das bedeutet, dass Entwickler keine Bibliotheken oder zusätzliche Software installieren müssen, um die Vorteile eines REST-API-Designs zu nutzen. Das REST-API-Design wurde von Dr. Roy Fielding in seiner im Jahr 2000 abgeschlossenen Doktorarbeit definiert. Es zeichnet sich durch seine unglaubliche Flexibilität aus. Da Daten nicht an Methoden und Ressourcen gebunden sind, hat REST die Fähigkeit, mehrere Arten von Aufrufen zu verarbeiten, verschiedene Datenformate zurückzugeben und sich sogar strukturell mit der richtigen Implementierung von Hypermedien zu ändern.

Dank dieser Flexibilität des REST-API-Designs können Sie eine API erstellen, die Ihren Anforderungen entspricht und gleichzeitig die Bedürfnisse der unterschiedlichsten Kunden erfüllt. Im Gegensatz zu SOAP ist REST nicht auf XML beschränkt, sondern kann XML, JSON, YAML oder beliebige andere Formate zurückgeben, je nachdem, was der Client anfordert. Anders als beim Remote Procedure Call (RPC) müssen Benutzer keine Prozedurnamen oder bestimmten Parameter in einer genauen Reihenfolge kennen.

Das REST-API-Design hat jedoch auch Nachteile. Sie können die Fähigkeit verlieren, den Zustand in REST aufrechtzuerhalten, zum Beispiel innerhalb von Sitzungen. Außerdem kann REST für Entwickler mit weniger Erfahrung schwieriger sein. Bevor Sie Ihre API erstellen, müssen Sie die Kriterien einer REST-API einschließlich der Gründe verstehen. Wenn Sie das jeweilige Design nicht nachvollziehen können, erzielen Sie möglicherweise keine optimalen Ergebnisse.

Obwohl die meisten APIs als RESTful gelten, erfüllen sie nicht alle die von Dr. Fielding definierten Anforderungen und Prinzipien. Es gibt sechs wichtige Prinzipien für das REST-API-Design, die Sie bei der Entscheidung bezüglich des für Ihr Projekt geeigneten API-Typs beachten sollten.

Das Prinzip des Client-Server-Modells beruht auf dem Konzept, dass der Client und der Server getrennt voneinander sein sollten und sich einzeln und unabhängig entwickeln dürfen. Sie sollten also in der Lage sein, Änderungen an Ihrer Anwendung für Mobilgeräte vorzunehmen, ohne dadurch die Datenstruktur oder das Datenbankdesign auf dem Server zu beeinträchtigen. Gleichzeitig sollte es möglich sein, die Datenbank zu ändern oder Änderungen an Ihrer Serveranwendung vorzunehmen, ohne den mobilen Client zu beeinträchtigen. Dadurch entsteht eine Trennung der Zuständigkeiten, sodass alle Anwendungen unabhängig voneinander wachsen und skaliert werden können. Dies ermöglicht Ihrem Unternehmen ein schnelles und effizientes Wachstum.

REST-APIs sind zustandslos. Die Aufrufe können unabhängig voneinander erfolgen, und jeder Aufruf beinhaltet alle für die erfolgreiche Durchführung erforderlichen Daten. Eine REST-API sollte nicht darauf angewiesen sein, dass Daten auf dem Server oder in Sitzungen gespeichert werden. Sie versteht die Nachricht einzig und allein aufgrund der im jeweiligen Aufruf enthaltenen Daten. Identifikationsdaten werden bei Aufrufen nicht auf dem Server gespeichert. Stattdessen beinhaltet jeder Aufruf die notwendigen Daten, wie zum Beispiel den API-Schlüssel, das Zugriffstoken und die Benutzer-ID. Dies begünstigt die Zuverlässigkeit der API. Alle für den Aufruf erforderlichen Daten stehen zur Verfügung, und beim Erstellen eines Objekts ist es nicht notwendig, sich auf eine Reihe von Aufrufen mit Serverzustand zu verlassen, was Teilausfälle verursachen könnte. Zur Reduzierung des Speicherbedarfs und zur Beibehaltung der Skalierbarkeit Ihrer Anwendung müssen bei einer RESTful-API alle Zustände auf dem Client und nicht auf dem Server gespeichert werden.

Durch die Verarbeitung großer Mengen ein- und ausgehender Aufrufe kann eine zustandslose API das Aufkommen von Aufrufen erhöhen. Daher sollte eine REST-API die Speicherung Cache-fähiger Daten unterstützen. Wenn die Daten Cache-fähig sind, gilt Folgendes: Die Antwort sollte beinhalten, dass die Daten bis zu einem bestimmten Zeitpunkt gespeichert werden können (expires-at). Bei Daten, die in Echtzeit vorliegen müssen, sollte angemerkt werden, dass die Antwort nicht vom Client zwischengespeichert werden sollte. Durch Einhaltung dieses wichtigen Prinzips reduzieren Sie die Interaktionen mit Ihrer API und somit die Nutzung des internen Servers ganz erheblich. Außerdem stellen Sie den Benutzern Ihrer API die Tools zur Verfügung, die zur Bereitstellung der schnellsten und effizientesten Apps notwendig sind. Denken Sie daran, dass das Caching auf dem Client erfolgt. Sie können zwar einige Daten innerhalb Ihrer Architektur zwischenspeichern, um die Gesamtleistung zu verbessern. Es geht jedoch darum, dem Client mitzuteilen, wie er vorgehen soll und ob er die Daten vorübergehend speichern kann.

Um den Client vom Server zu entkoppeln, ist eine einheitliche Schnittstelle erforderlich. Sie muss eine unabhängige Entwicklung der Anwendung ermöglichen, ohne dass die Services, Modelle oder Aktionen der Anwendung eng mit der API-Ebene verbunden sind. Über die einheitliche Schnittstelle kann der Client in einer einzigen Sprache mit dem Server kommunizieren. Dabei spielt die Architektur des Client- und Server-Backends keine Rolle. Diese Schnittstelle sollte ein unveränderliches, standardisiertes Mittel zur Kommunikation zwischen Client und Server bereitstellen, zum Beispiel über HTTP mit URI-Ressourcen, CRUD (Create, Read, Update, Delete) und JSON.

Wie der Name schon sagt, besteht ein mehrschichtiges System aus mehreren Schichten. Dabei hat jede Schicht eine bestimmte Funktion und Verantwortung. Bei einem Model-View-Controller-Framework hat zum Beispiel jede Schicht ihre eigenen Verantwortungen: Die Modelle bestimmen, wie die Daten gebildet werden sollen, der Controller konzentriert sich auf die eingehenden Aktionen, und die View konzentriert sich auf die Ausgabe. Die Schichten sind voneinander getrennt, kommunizieren aber miteinander. Beim REST-API-Design gilt dasselbe Prinzip: Die verschiedenen Schichten der Architektur bilden gemeinsam eine Hierarchie, die zur Entstehung einer skalierbaren und modularen Anwendung beiträgt.

In ein Schichtensystem lassen sich auch Legacy-Systeme einbinden und selten genutzte Funktionen in einen gemeinsamen Vermittler verschieben, während aktuellere und häufig genutzte Komponenten von diesen Daten abgeschirmt werden. Darüber hinaus können Sie in einem Schichtensystem Ihre Architektur um neue Systeme erweitern oder andere daraus entfernen, wenn neue Technologien und Services entstehen. Dies erhöht Flexibilität und Lebensdauer, solange Sie die verschiedenen Module möglichst lose koppeln. Für die Sicherheit ist ein Schichtensystem ein großer Vorteil. Sie können Angriffe in der Proxy-Schicht oder in anderen Schichten abfangen, sodass sie nicht in die eigentliche Server-Architektur gelangen. Wenn Sie ein Schichtensystem mit einem Proxy verwenden oder einen zentralen Zugangspunkt erstellen, sind Sie in der Lage, wichtige und anfälligere Aspekte Ihrer Architektur durch eine Firewall zu schützen, sodass sie keinen direkten Kontakt mit dem Client haben. Die Sicherheit kann nicht durch eine einzige allumfassende Lösung gewährleistet werden. Mehrere Schichten sind effektiver, denn Sie müssen bedenken, dass einige Sicherheitsprüfungen fehlschlagen oder umgangen werden können. Je mehr Sicherheitsvorkehrungen Sie in Ihrem System implementieren, desto wahrscheinlicher ist es, dass Sie verheerende Angriffe abwehren.

Code on Demand ist optional und möglicherweise das weniger bekannte der sechs Prinzipien. Es ermöglicht die Übertragung von Code oder Applets über die API zur Nutzung in der Anwendung. Dabei wird eine intelligente Anwendung erstellt, die nicht mehr ausschließlich von ihrer eigenen Code-Struktur abhängig ist. Code on Demand wird bisher nur selten verwendet. Möglicherweise liegt es daran, dass es seiner Zeit voraus ist. Web-APIs werden in vielen verschiedenen Sprachen genutzt, und die Übertragung des Codes wirft Fragen bezüglich der Sicherheit auf. (Das Verzeichnis müsste beispielsweise beschreibbar sein und die Firewall müsste Inhalte zulassen, die normalerweise als beschränkte Inhalte gelten.)

In ihrer Gesamtheit bilden diese Prinzipien die Theorie von Representational State Transfer (REST). Sie werden feststellen, dass diese Prinzipien aufeinander aufbauen und letztendlich eine recht komplizierte, aber leistungsstarke und flexible, Application Programming Interface (API) bilden. Der wichtigste Aspekt ist jedoch, dass diese Prinzipien ein Design ergeben, das ähnlich wie der Zugriff auf Seiten in unseren Browsern im World Wide Web funktioniert. Das Ergebnis ist eine API, die nicht von ihrer Architektur bestimmt wird, sondern von den Repräsentationen, die sie zurückgibt. Während die Architektur dieser API zustandslos ist, verlässt sich die API auf die Repräsentation, um den Zustand der Anwendung zu bestimmen.