Architektonische Einschränkungen der REST-API

Die bekannte Abkürzung steht für „Representational State Transfer“, einen Stil der Softwarearchitektur. Am häufigsten wird er eingesetzt, um die Nutzung von Webdiensten durch einen standardisierten, universellen Ansatz zu vereinfachen.

Diese Webdienste stellen ihre Webressourcen in textueller Form bereit und ermöglichen es, diese mit einem zustandslosen Protokoll zu lesen und zu verarbeiten. Die Operationen, die ein Client ausführen kann, sind vordefiniert und bekannt und basieren in der Regel auf den HTTP-Protokollen.

RESTful-APIs und -Software basieren nicht auf technologischen oder programmiertechnischen Neuerungen. Sie sind nicht einmal besonders neu, da sie bereits im Jahr 2000 konzipiert wurden. Die Idee hinter REST ist es, der API bestimmte Regeln aufzuerlegen, um mehr Leistung, Skalierbarkeit, Einfachheit, Modifizierbarkeit, Transparenz, Portabilität und Zuverlässigkeit zu erzielen.

Das sind viele Vorteile, aber wie erreichen REST-APIs diese, fragen Sie sich vielleicht? Ganz einfach: durch die Einhaltung von sechs Einschränkungen. Tatsächlich sind diese Regeln die charakteristischsten Merkmale des RESTful-Architekturstils.

Die Aufgabe einer API besteht darin, zwei Softwarekomponenten miteinander zu verbinden, ohne deren eigene Funktionalitäten einzuschränken. Dieses Ziel ist eine der zentralen Einschränkungen von REST: Der Client (der Anfragen stellt) und der Server (der Antworten liefert) bleiben getrennt und unabhängig voneinander.

Wenn dies richtig umgesetzt wird, können sich Client und Server in unterschiedliche Richtungen weiterentwickeln, ohne dass dies Auswirkungen auf die Qualität ihres Datenaustauschs hat. Dies ist besonders wichtig in Fällen, in denen ein Server eine Vielzahl unterschiedlicher Clients bedienen muss. Denken Sie an Wetter-APIs – sie müssen Daten aus einer einzigen Datenbank an unzählige verschiedene Clients senden (alle Arten von Mobilgeräten sind gute Beispiele dafür).

Damit eine API zustandslos ist, muss sie Aufrufe unabhängig voneinander verarbeiten. Jeder API-Aufruf muss die Daten und Befehle enthalten, die zur Ausführung der gewünschten Aktion erforderlich sind.

Ein Beispiel für eine nicht zustandsbehaftete API wäre, wenn während einer Sitzung nur der erste Aufruf den API-Schlüssel enthalten muss, der dann serverseitig gespeichert wird. Die folgenden API-Aufrufe hängen von diesem ersten ab, da er die Anmeldedaten des Clients bereitstellt.

Im gleichen Fall stellt eine zustandslose API sicher, dass jeder Aufruf den API-Schlüssel enthält und der Server jedes Mal einen Zugriffsnachweis erwartet.

Zustandslose APIs haben den Vorteil, dass ein fehlerhafter oder fehlgeschlagener Aufruf die nachfolgenden nicht beeinträchtigt.

Auch wenn sich Client und Server auf unterschiedliche Weise ändern, ist es wichtig, dass die API weiterhin die Kommunikation ermöglicht. Zu diesem Zweck schreiben REST-APIs eine einheitliche Schnittstelle vor, die problemlos alle angeschlossenen Softwarekomponenten integrieren kann.

In den meisten Fällen basiert diese Schnittstelle auf den HTTP-Protokollen. Abgesehen davon, dass sie Regeln für die Interaktion zwischen Client und Server festlegt, hat sie auch den Vorteil, dass sie im Internet weithin bekannt ist und verwendet wird. Daten werden aufgrund ihrer Vielseitigkeit in JSON-Dateien gespeichert und ausgetauscht.

Um die API leicht verständlich und skalierbar zu halten, schreibt die RESTful-Architektur vor, dass das Design in Schichten strukturiert ist, die zusammenarbeiten.

Dank einer klaren Hierarchie dieser Schichten bedeutet die Ausführung eines Befehls, dass jede Schicht ihre Funktion erfüllt und die Daten anschließend an die nächste weiterleitet. Verbundene Schichten kommunizieren untereinander, jedoch nicht mit jeder Komponente des Programms. Auf diese Weise wird auch die Gesamtsicherheit der API verbessert.

Ändert sich der Umfang der API, können Schichten hinzugefügt, geändert oder entfernt werden, ohne andere Komponenten der Schnittstelle zu beeinträchtigen.

Es ist nicht ungewöhnlich, dass Anfragen an eine zustandslose API einen hohen Overhead verursachen. In manchen Fällen ist das unvermeidbar, aber bei wiederholten Anfragen, die dieselben Daten benötigen, kann das Zwischenspeichern dieser Informationen einen großen Unterschied machen.

Das Konzept ist einfach: Der Client hat die Möglichkeit, bestimmte Daten für einen festgelegten Zeitraum lokal zu speichern. Wenn er eine Anfrage für diese Daten stellt, verwendet er die gespeicherte Version, anstatt dass der Server sie erneut sendet.

Das Ergebnis ist einfach: Anstatt dass der Client innerhalb kurzer Zeit mehrere aufwendige oder kostspielige Anfragen sendet, muss er dies nur einmal tun.

Im Gegensatz zu den anderen Einschränkungen, über die wir bisher gesprochen haben, ist die letzte optional. Der Grund dafür, „Code on Demand“ optional zu machen, ist einfach: Es kann ein großes Sicherheitsrisiko darstellen.

Das Konzept besteht darin, zu ermöglichen, dass Code oder Applets über die API gesendet und für die Anwendung genutzt werden. Wie Sie sich vorstellen können, könnte unbekannter Code aus einer zwielichtigen Quelle Schaden anrichten; daher sollte diese Einschränkung am besten auf interne APIs beschränkt bleiben, bei denen Sie weniger Angst vor Hackern und Personen mit bösen Absichten haben müssen. Ein weiterer Nachteil ist, dass der Code in der für die Anwendung geeigneten Programmiersprache vorliegen muss, was nicht immer der Fall ist.

Der Vorteil ist, dass „Code on Demand“ dem Kunden helfen kann, eigene Funktionen spontan zu implementieren, wobei weniger Arbeit auf der API- oder Serverseite erforderlich ist. Im Wesentlichen ermöglicht es, das gesamte System wesentlich skalierbarer und agiler zu gestalten.

Der Schwerpunkt des RESTful-Designs liegt auf Effizienz und Skalierbarkeit in einer vom Web dominierten Welt. Wie man sich vorstellen kann, hat dies diese Architektur sehr beliebt gemacht, und wir werden höchstwahrscheinlich erleben, dass sie sich in den kommenden Jahren noch weiter verbreitet.

Das Hauptanliegen vieler Entwickler und Sicherheitsexperten ist die Frage, wie anfällig Web-APIs für Angriffe sein können, wenn sie ohne die nötige Sorgfalt erstellt werden. Natürlich waren und bleiben Hacker ein Problem für APIs und Software im Allgemeinen. Dennoch werden wir nicht aufhören, sie zu nutzen. Vielmehr ist es Aufgabe der Sicherheitsexperten, neue Wege zu finden, um unsere Programme zu schützen.

Diese Denkweise, zusammen mit dem Ziel, Entwicklern das Leben zu erleichtern, hat uns dazu veranlasst, WebScrapingAPI zu entwickeln – eine REST-API zur Datenextraktion, die alles abdeckt, von Proxy-Rotation über JavaScript-Rendering bis hin zur Lösung von CAPTCHAs. Probieren Sie es aus und sehen Sie selbst, was eine REST-API leisten kann!