Beschränkungen der Rest-API-Architektur

Sorin-Gabriel Marica am 08. Dezember 2022

APIs gibt es in vielen Formen und Größen. Während viele Entwickler APIs dafür danken, dass sie ihre Arbeit auf hundert verschiedene Arten erleichtern, nehmen sich nicht viele die Zeit, mehr über diese Schnittstellen zu erfahren.

Wir haben es verstanden. Die Zeit ist begrenzt, und zu verstehen, was eine REST-API ausmacht, ist vielleicht nicht für jeden sinnvoll. Das wollen wir auch gar nicht bestreiten, aber es gibt einen Grund, warum so gut wie jeder das lernen sollte: Es ist verdammt interessant. Außerdem zahlt es sich aus, mehr darüber zu wissen, wenn Sie eine API entwerfen oder mit ihr arbeiten wollen.

In diesem Artikel werden wir einen Blick unter die Haube von REST-APIs werfen und verstehen, wie ihre Konstruktionsprinzipien sie zu der stabilen Software gemacht haben, die sie heute sind.

Was es bedeutet, RESTful zu sein

Die berühmte Abkürzung steht für "Representational State Transfer", einen Software-Architekturstil. Seine häufigste Verwendung ist die Erleichterung der Nutzung von Webdiensten mit einem standardisierten, universellen Ansatz.

Diese Webdienste bieten ihre Webressourcen in einer textuellen Darstellung an und ermöglichen es, sie mit einem zustandslosen Protokoll zu lesen und zu verarbeiten. Die Operationen, die ein Client ausführen kann, sind vordefiniert und bekannt und basieren im Allgemeinen auf den HTTP-Protokollen.

RESTful APIs und Software beruhen nicht auf einem technologischen oder programmiertechnischen Fortschritt. Sie sind noch nicht einmal so neu, denn sie wurden erstmals im Jahr 2000 erdacht. Die Idee hinter REST ist es, der API bestimmte Regeln aufzuerlegen, damit Sie mehr Leistung, Skalierbarkeit, Einfachheit, Änderbarkeit, Sichtbarkeit, Portabilität und Zuverlässigkeit erhalten.

Das sind eine Menge Vorteile, aber wie erreichen REST-APIs diese, werden Sie sich fragen? Ganz einfach, indem sie sechs Einschränkungen befolgen. In der Tat sind diese Regeln die wichtigsten Merkmale des RESTful-Architekturstils.

Die sechs architektonischen Beschränkungen von REST-APIs

1. Client-Server-Architektur

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

Wenn dies richtig gemacht wird, können Client und Server Aktualisierungen vornehmen und sich in unterschiedliche Richtungen entwickeln, ohne dass die Qualität ihres Datenaustauschs beeinträchtigt wird. Dies ist besonders wichtig in Fällen, in denen ein Server viele verschiedene Clients bedienen muss. Denken Sie an Wetter-APIs - sie müssen von einer einzigen Datenbank aus Daten an viele verschiedene Clients (alle Arten von Mobilgeräten sind gute Beispiele) senden.

2. Staatenlosigkeit

Damit eine API zustandslos sein kann, muss sie Aufrufe unabhängig voneinander verarbeiten. Jeder API-Aufruf muss die Daten und Befehle enthalten, die erforderlich sind, um die gewünschte Aktion auszuführen.

Ein Beispiel für eine nicht zustandslose 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 Aufruf ab, da er die Anmeldedaten des Kunden enthält.

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

Zustandslose APIs haben den Vorteil, dass ein einziger fehlerhafter oder fehlgeschlagener Aufruf die nachfolgenden nicht zum Entgleisen bringt.

3. Einheitliche Schnittstelle

Auch wenn sich der Client und der Server auf unterschiedliche Weise verändern, ist es wichtig, dass die API die Kommunikation weiterhin erleichtern kann. Zu diesem Zweck setzen REST-APIs eine einheitliche Schnittstelle voraus, die sich problemlos an alle angeschlossenen Programme anpassen lässt.

In den meisten Fällen basiert diese Schnittstelle auf den HTTP-Protokollen. Neben der Tatsache, dass es Regeln für die Interaktion zwischen Client und Server festlegt, hat es auch den Vorteil, dass es im Internet weithin bekannt ist und verwendet wird. Die Speicherung und der Austausch von Daten erfolgt aufgrund ihrer Vielseitigkeit über JSON-Dateien.

4. Mehrschichtiges System

Damit die API einfach zu verstehen und zu skalieren ist, schreibt die RESTful-Architektur vor, dass das Design in Schichten strukturiert ist, die zusammenarbeiten.

Mit einer klaren Hierarchie für diese Schichten bedeutet die Ausführung eines Befehls, dass jede Schicht ihre Funktion ausführt und dann die Daten an die nächste Schicht sendet. Verbundene Schichten kommunizieren miteinander, aber nicht mit jeder Komponente des Programms. Auf diese Weise wird auch die allgemeine Sicherheit der API verbessert.

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

5. Cachefähigkeit

Es ist nicht ungewöhnlich, dass die Anforderungen einer zustandslosen API einen großen Overhead haben. In manchen Fällen ist das unvermeidlich, aber bei wiederholten Anfragen, die dieselben Daten benötigen, kann das Zwischenspeichern dieser Informationen einen großen Unterschied machen.

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

Das Ergebnis ist einfach: Anstatt mehrere schwierige oder kostspielige Anfragen in kurzer Zeit zu stellen, muss der Kunde dies nur einmal tun.

6. Code auf Abruf

Im Gegensatz zu den anderen Einschränkungen, über die wir bis zu diesem Punkt gesprochen haben, ist die letzte optional. Der Grund dafür, dass "Code on demand" optional ist, ist einfach: Er kann ein großes Sicherheitsrisiko darstellen.

Das Konzept sieht vor, dass Code oder Applets über die API gesendet und für die Anwendung verwendet werden können. Wie Sie sich vorstellen können, könnte unbekannter Code aus einer zwielichtigen Quelle einigen Schaden anrichten. Daher ist diese Einschränkung am besten für interne APIs geeignet, bei denen Sie weniger von Hackern und Menschen mit schlechten Absichten zu befürchten haben. 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, seine eigenen Funktionen unterwegs zu implementieren, wobei weniger Arbeit an der API oder dem Server erforderlich ist. Das gesamte System wird dadurch wesentlich skalierbarer und flexibler.

Sind REST-APIs der Weg in die Zukunft?

Der Schwerpunkt des RESTful-Designs liegt auf Effizienz und Skalierbarkeit in einer vom Web dominierten Welt. Wie Sie sich vorstellen können, hat dies die Architektur sehr populär gemacht und wird sich in den kommenden Jahren wahrscheinlich noch weiter verbreiten.

Die Hauptsorge vieler Entwickler und Sicherheitsexperten ist, wie angreifbar Web-APIs sind, wenn sie ohne entsprechende Sorgfalt erstellt werden. Natürlich waren und sind Hacker auch in Zukunft ein Problem für APIs und Software im Allgemeinen. Dennoch ist es nicht so, dass wir aufhören werden, sie zu verwenden. Vielmehr liegt es an den Sicherheitsexperten, neue Wege zum Schutz unserer Programme zu finden.

Diese Denkweise und das Ziel, Entwicklern das Leben leichter zu machen, haben uns dazu gebracht, WebScrapingAPI zu entwickeln, eine REST-API zur Datenextraktion, die alles von Proxy-Rotation über Javascript-Rendering bis zum Lösen von CAPTCHAs abdeckt. Schauen Sie sich an, was eine REST-API leisten kann!