REST-API: Definition, Funktionen und Bedingungen

REST-API hat sich über die Jahre zur vielseitigsten und nützlichsten Webservice-API entwickelt. Aufgrund ihrer Flexibilität, Einfachheit, und Kompatibilität ist sie für die Arbeit mit verschiedenen Datentypen geeignet und an die bekanntesten Apps gekoppelt. Erfahren Sie im Folgenden, was eine REST(oder RESTful)-API ist, wie sie funktioniert, wie sie sich von ihrem Vorgänger SOAP unterscheidet und warum REST-APIs für Unternehmen so relevant sind.

Was ist eine REST-API? – Definition

REST- (Representational State Transfer) bzw. RESTful-API ist ein Application-Program-Interface-Typ (API-Typ), der webbasierte Apps in der Kommunikation miteinander unterstützt. Obwohl die API theoretisch mit jedem Protokoll oder Datenformat kompatibel ist, verwendet REST in den meisten Fällen das HTTP-Protokoll und überträgt die Daten mithilfe von JSON (JavaScript Object Notation). Die REST-API ist aufgrund ihrer Flexibilität, Schnelligkeit und Einfachheit eine der beliebtesten Varianten, um Daten aus dem Internet zu bekommen.

Bis zum Jahr 2000 war SOAP (Simple Object Access Protocol), das von Microsoft entwickelt wurde, die am weitesten verbreitete Plattform für Client-Server-Interaktionen. SOAP war zwar beliebt und durchaus nützlich, hatte aber zwei konkrete Nachteile: Erstens mussten sich die Nutzer bei der Interaktion mit dem Server an strenge Regeln halten. Zweitens basierte das Protokoll auf dem umständlichen XML-Format.

Der US-amerikanische Informatiker Roy Fielding war mit der SOAP-Methode unzufrieden und entwickelte im Rahmen seiner Doktorarbeit aus dem Jahr 2000 eine Alternative namens „REST“. Die REST-Schnittstelle hebt sich durch ihre größere Flexibilität bei der Formatierung, eine höhere Geschwindigkeit und eine geringere Bandbreite von ihrem Vorgänger ab. Heute ist REST eine der gängigsten APIs und wird von den meisten großen Plattformen wie Amazon, Facebook, Twitter und Google verwendet.

Funktionen der REST-Schnittstelle

Wie alle APIs dient auch REST dazu, Daten zwischen Nutzern und Apps auszutauschen. Wenn Sie sich zum Beispiel bei einer Website anmelden oder auf eine App auf Ihrem Smartphone zugreifen, unterstützt eine API Ihren Client bei der Kommunikation mit dem Server. APIs übermitteln Ihre Anfragen an den Server und leiten die Antwort des Servers an Sie weiter.

Client-Anfrage

Der Prozess startet, wenn ein Client in der REST-Architektur HTTP-Befehle verwendet, um Anfragen an den Server zu senden. Wenn Sie zum Beispiel eine Webseite öffnen, indem Sie eine URL eingeben, senden Sie eigentlich eine HTTP-Anweisung wie „GET + URL“. Ein REST-Client verwendet ähnliche Befehle, um auf die von Ihnen angeforderten Informationen zuzugreifen. Zu den gängigsten HTTP-Befehlen gehören:

• GET – Abrufen einer bestimmten Ressource
• POST – Erstellen einer neuen Ressource
• PUT – Aktualisieren einer vorhandenen Ressource
• DELETE – Löschen einer vorhandenen Ressource

Wenn Sie beispielsweise den HTTP-Befehl „GET https://api.buchhaendler.de/kunden/“ eingeben, rufen Sie die Namen aller Kunden auf der Website des Buchhändlers ab.

Server-Antwort

Sobald eine Client-Anfrage eingegangen ist, sucht die REST-API nach einer Antwort und liefert sie unverzüglich. Sie greift dabei auf verschiedene Ressourcen zurück – zum Beispiel:

• Daten
• Bilder
• Videos
• Webadressen
• Kommentare
• Blogbeiträge
• Tweets usw.

Wenn der Client eine Ressource vom Server anfordert, sendet der Server nicht die Ressource selbst zurück, sondern antwortet mit einer Darstellung der Ressource.

Die Antworten werden meist im JSON-Format geliefert. Das Format ist sowohl für Menschen als auch Maschinen lesbar. Aufgrund seiner Kompatibilität mit den meisten Programmiersprachen ist es daher bestens für die REST-API geeignet.

6 architektonische Bedingungen der REST-API

1. Einheitliche Schnittstelle
2. Client-Server-Architektur
3. Zustandslosigkeit (Statelessness)
4. Schichtsystem
5. Zwischenspeicher
6. Code-on-demand

Ein großer Vorteil der REST-API sind ihre überschaubaren Anforderungen an die Syntax. Allerdings unterliegt die REST-API einigen Regeln, den sogenannten „Constraints“. Damit eine API als RESTful gilt, muss sie die folgenden sechs Bedingungen erfüllen:

Einheitliche Schnittstelle (Uniform Interface)

Eine einheitliche Schnittstelle bedeutet, dass jeder REST-Client den Server auf die gleiche Weise aufrufen und auf seine Ressourcen zugreifen kann – unabhängig davon, ob der Client ein Browser, JavaScript-Code oder eine mobile Anwendung ist. Die Verwendung einer URI (Unique Resource Identifier), die oft eine URL wie zum Beispiel „https://api.twitter.com/“ ist, macht dies möglich.

Anfragen und Antworten müssen autark (self-sufficient) sein – der Client sendet alle Informationen, die der Server benötigt, um die Anfrage zu verarbeiten. Der Server antwortet mit einer Information darüber, die angeforderte Ressource zu ändern, zu löschen oder auf sie zuzugreifen.

Der Server muss die Möglichkeit haben, Hyperlinks einzubinden. Diese erlauben es dem Client, Änderungen an der Ressource vorzunehmen. Diese Eigenschaft ist als "Hypermedia As The Engine Of Application State" (HATEOAS) bekannt.

Client-Server-Architektur

In der REST-Architektur sind die Client- und Server-Komponenten klar definiert und voneinander getrennt. Dieser Aufbau ermöglicht es, dass Änderungen an beiden Komponenten unabhängig voneinander vorgenommen werden können, ohne dass dies Auswirkungen auf die jeweils andere Komponente hat. Die meisten Web-Clients und -Server sind auf diese Weise konzipiert; bei einem REST-Interface ist diese Bedingung einfach explizit genannt.

Zustandslosigkeit (Statelessness)

In einem RESTful-Design sind die Interaktionen zwischen Client und Server zustandslos. Das bedeutet, dass der Server den Anwendungszustand des Clients nicht in einem Speicher oder in einer Datenbank abspeichern muss. Daher müssen schon in der Anfrage alle notwendigen Informationen für den Datenaustausch enthalten sein.

Zustandslosigkeit bedeutet auch, dass ausschließlich der Client dafür zuständig ist, den Anwendungszustand aufrecht zu erhalten. Auf diese Weise wird der Server entlastet, da er keine Overhead-Daten über Client-Aufrufe speichern muss, um künftige Anfragen zu bearbeiten.

Die Skalierbarkeit ist in einer zustandslosen Architektur einfacher. Es kann jedoch passieren, dass der Client die Server mehrmals kontaktieren muss, um Daten zu erhalten, was die Leistung beeinträchtigt. Web-Entwickler können im Normalfall die Leistung von Client-Anwendungen optimieren, indem sie die Anzahl der „Hops“ zum Server reduzieren.

Schichtsystem

Ein geschichtetes System beschreibt die vollständige Trennung von Client und Server. Wenn ein Client eine Anfrage über eine Server-Endpunkt-URL stellt, muss er nicht genau wissen, welcher Server seine Anfrage bearbeitet. In einem mehrschichtigen System kann es verschiedene Server geben, die alle eine eigene Aufgabe haben, wie z. B. Load Balancing, Caching usw. Der Client bekommt von all diesen Aktionen im Hintergrund nichts mit.

Die Schichtung verleiht der REST-API zusätzliche Sicherheit, da Angriffe innerhalb einzelner Schichten isoliert und eingedämmt werden können. Dadurch gefährden Angriffe nie die gesamte Architektur.

Zwischenspeicher

REST-Server können Daten zwischenspeichern. Mithilfe des Cache-Control-Headers teilt der Server seinem Client mit, ob die gesendeten Daten zwischengespeichert werden sollen (oder nicht) und wie lange die jeweilige Antwort gültig ist. Nach Ablauf der Gültigkeit kontaktiert der Client den Server erneut, um ein Update zu erhalten. Versionsnummern werden ebenfalls verwendet, damit der Client feststellen kann, ob die Ressource auf dem neusten Stand ist.

Code-on-demand

In einem RESTful-Design ist dies die einzige Bedingung, die optional ist. Code-on-demand ist eine Funktion, bei der der Server einen Code-Schnipsel sendet, den der Client dann ausführt. Der Code kann zum Beispiel als JavaScript innerhalb einer HTML-Antwort gesendet werden.

Die 6 Unterschiede zwischen SOAP und REST-Schnittstellen

Seit fast zwei Jahrzehnten wird über SOAP und REST debattiert. Jede Schnittstelle hat ihren eigenen Nutzen, jede ihre eigenen Stärken und Schwächen. Obwohl viele Unternehmen weiterhin auf SOAP setzen, hat sich REST aufgrund seiner Anpassungsfähigkeit und einfachen Architektur als die beliebteste API herauskristallisiert. Um zu verstehen, was REST von SOAP unterscheidet, lohnt sich ein kurzer Vergleich:

1. SOAP ist ein Protokoll, REST ein Designstil.
2. REST ist schneller, da es weniger Bandbreite und Ressourcen braucht.
3. SOAP erfordert eine engere Bindung zwischen Client und Server.
4. REST bietet eine klarere Client-Server-Trennung als SOAP.
5. REST-Aufrufe können zwischengespeichert werden.
6. SOAP gilt als sicherer.

1. SOAP ist ein Protokoll, REST ein Designstil. SOAP erfordert viel strengere Standards für die Kommunikation und die Syntax, während REST nur sechs Bedingungen festlegt und mehr Flexibilität bei der Implementierung zulässt.

2. REST ist leistungsfähiger, da es weniger Bandbreite und Ressourcen braucht. SOAP arbeitet nur mit dem XML-Datenformat, weswegen die Dateien oft sehr groß sind. REST arbeitet mit weniger sperrigen Formaten wie HTML, JSON oder sogar einfachem Text.

3. SOAP erfordert eine engere Bindung zwischen Client und Server. Wenn die SOAP-Server-Funktion aufgerufen wird, muss der SOAP-Client die genaue Signatur dieser Funktionen kennen. Wenn sich die Signatur ändert, kommt es zu Unterbrechung.

4. REST bietet eine klarere Client-Server-Trennung als SOAP. Der REST-Client muss die Details der API-Implementierung nicht kennen, weil er nur die Namen der Ressourcen aufruft. Wenn der Server seine Implementierung ändert, muss der Client überhaupt keine Änderungen vornehmen.

5. REST-Aufrufe können zwischengespeichert werden. Mittels der Cache-Eigenschaft von REST-APIs können Daten vom Webbrowser wiederverwendet werden können. Diese elegante Design-Option hilft dabei, Bandbreite zu sparen.

6. SOAP gilt als sicherer. SOAP unterstützt die WS-Security- und SSL-Standards. Es verfügt außerdem über eine eingebaute ACID (Atomicity, Consistency, Isolation, Durability)-Konformität. Daher ist SOAP besser geeignet für Unternehmensanwendungen und Systeme, die mit hochsensiblen Daten arbeiten (wie z. B. Bezahl-Gateways und Telekommunikationsdienste). REST unterstützt allerdings die SSL- und HTTPS-Standards.

REST-API und Cloud-Integration

Der größte Trend in der Datenverwaltung ist die Entwicklung hin zur Cloud-Integration. APIs ermöglichen es Nutzern, auf Informationen zuzugreifen, die in der Cloud auf mehreren Servern und in verschiedenen Formaten gespeichert sind. Obwohl REST-APIs am häufigsten mit SaaS-Plattformen („Software as a Service“) verwendet werden, spielen sie auch für PaaS-Anbieter („Platform as a Service“) eine wichtige Rolle. Einige der bekanntesten Anbieter, die RESTful APIs verwenden, sind Oracle, Jira, Google, Adobe, Amazon und GitHub.

Beim Cloud Computing steht viel auf dem Spiel. Aus diesem Grund möchten Unternehmen sicherstellen, dass ihre Produkte und Services die volle Funktionalität der Cloud nutzen können. In den meisten Fällen bedeutet dies die Verwendung eines Cloud-Integrationstools, das REST-API-Konnektoren und -Funktionen bereitstellt.

Die Cloud-API-Services von Talend vereinfachen die Erstellung von APIs und ermöglichen es Ihnen, das meiste aus Ihren Daten herauszuholen. Mit einem kompletten Satz an Tools und über 900 Konnektoren können Sie Ihre APIs schneller als je zuvor zum Laufen bringen und die Qualität Ihrer Daten sicherstellen. Laden Sie noch heute eine kostenlose Testversion herunter und überzeugen Sie sich selbst, wie einfach die Cloud-Integration sein kann.