Was ist eine REST-API?

Eine REST-API ist eine Art von Programmierschnittstelle (API), die dem Modell des Representational State Transfer (REST) für die Darstellung von Daten und die Kommunikation zwischen zwei Systemen (einem Client und einem Server) über ein Netzwerk wie das Internet entspricht. REST-APIs unterstützen den Informationsaustausch zwischen internen Anwendungen und Anwendungen von Drittanbietern und ermöglichen es Unternehmen, mehrere Endpunkte in ihr Anwendungsökosystem zu integrieren.

Hinweis: Streng genommen bezeichnet REST das Modell und ist kein Adjektiv für eine API, die diesem Modell entspricht. Der korrekte Begriff dafür lautet RESTful API. Allerdings ist REST API die gebräuchlichere Bezeichnung und wird daher in diesem Artikel verwendet.

Was ist REST?

REST, was wie bereits erwähnt für Representational State Transfer steht, ist ein Architekturstil, der im Jahr 2000 vom Informatiker Roy Fielding entwickelt wurde. REST bietet Entwicklern Flexibilität und eignet sich daher ideal für die Verbindung von Anwendungen in Microservices-Architekturen.

REST definiert sechs Bedingungen, die Apps und APIs erfüllen müssen, um als RESTful zu gelten:

• Einheitliche Schnittstelle
• Client-Server-Architektur
• Zustandslosigkeit
• Mehrschichtiges System
• Cachefähigkeit
• Code-on-Demand

Weitere Informationen zu diesen Einschränkungen finden Sie auf Wikipedia.

Einheitliche Schnittstelle

Eine einheitliche Schnittstelle vereinfacht die gesamte Systemarchitektur und verbessert die Sichtbarkeit von Interaktionen. Zudem stellt sie bestimmte Anforderungen, um sicherzustellen, dass Informationen in einer standardisierten Form übertragen werden.

Vier Einschränkungen sorgen für eine einheitliche REST-Schnittstelle:

• Jede Ressource verfügt über eine eindeutige Kennung, beispielsweise einen URI, und die Darstellung der Ressource in einer Nachricht ist von der internen Darstellung auf dem Server getrennt.
• Die Repräsentation der Ressource enthält genügend Informationen, damit der Client den Zustand einer Ressource ändern oder löschen kann
• Jede Nachricht enthält genügend Informationen, um zu beschreiben, wie sie verarbeitet werden soll.
• Der Server verwendet Hyperlinks, um Clients über verfügbare Ressourcen zu informieren, sodass die Clients keine Kenntnisse über die internen Abläufe des Servers benötigen.

Client-Server

Eine Client-Server-Architektur besteht aus Clients, Servern und Ressourcen. Durch die Trennung der Benutzeroberfläche (vom Client gesteuert) von der Datenspeicherung (vom Server gesteuert) können sich die Client- und Serverkomponenten unabhängig voneinander weiterentwickeln. Dies erleichtert außerdem die Portierung der Client-Benutzeroberfläche auf verschiedene Plattformen sowie die Skalierung des Servers.

Im Internet erfolgt die Client-Server-Kommunikation über HTTP.

Zustandslosigkeit

Bei der Client-Server-Kommunikation bedeutet Zustandslosigkeit, dass der Server keine Informationen über den Client oder die mit ihm aufgebaute Sitzung speichert. Die Darstellung der sitzungsbezogenen Informationen durch den Client in jeder Nachricht muss es dem Server ermöglichen, diese unabhängig und ohne Kontext aus vorherigen Nachrichten zu verstehen. Dadurch wird die Serverlast reduziert und die Leistung von Anwendungen mit hohem Datenaufkommen verbessert.

Mehrschichtiges System

Clients müssen nicht wissen (und können in der Regel auch nicht erkennen), ob sie direkt mit dem Server oder mit einer Zwischeninstanz wie einem Reverse-Proxy oder Load-Balancer verbunden sind. Zwischenserver tragen zur Verbesserung der Skalierbarkeit bei und können Sicherheitsaufgaben übernehmen, sodass die Server nur für die Geschäftslogik zuständig sind.

Cache-Fähigkeit

HTTP-Clients und zwischengeschaltete Systeme können Serverantworten zwischenspeichern, um die Serverlast zu reduzieren und die Datenübertragung an Endbenutzer zu beschleunigen. Der Server muss angeben, ob eine Antwort zwischengespeichert werden darf oder nicht. Letzteres stellt sicher, dass die Antworten auf nachfolgende Anfragen von Endbenutzern korrekt und aktuell (also nicht möglicherweise „veraltet“) sind. Da Clients über die URL, die als eindeutige Kennung dient, auf eine Ressource zugreifen, können sie auf Ressourcenebene bestimmen, welche Daten zwischengespeichert werden sollen.

Code-on-Demand

Code-on-Demand bedeutet, dass der Server ausführbaren Code senden kann, um die Funktionalität des Clients vorübergehend zu erweitern oder anzupassen. Dadurch muss der Client diese Funktionalität nicht selbst implementieren. Die Code-on-Demand-Einschränkung ist optional.

Was ist eine Ressource?

Die wichtigste Datendarstellung oder Abstraktion in REST ist eine Ressource. Eine REST-Ressource kann jede Art von abstrahierter Information sein – von einem digitalen Dokument bis hin zu einem nicht digitalen Objekt. Der Zustand der Ressource zu einem bestimmten Zeitpunkt wird als Ressourcendarstellung bezeichnet.

Eine Ressourcendarstellung besteht aus drei Teilen:

• Daten
• Metadaten
• Hypermedia-Links

Eine REST-API besteht aus einer Zusammenstellung miteinander verknüpfter Ressourcen (dem sogenannten Ressourcenmodell), die über eindeutige URIs zugänglich sind. Ein Client kann flexible Funktionen bereitstellen, indem er innerhalb der Antwort auf zugehörige Ressourcen und URIs verweist. Im Allgemeinen wird eine Anfrage an eine REST-API als HTTP-GET-Anfrage gesendet; Server formatieren ihre Antworten häufig als JSON.

Die folgenden HTTP-Anfragemethoden werden verwendet, um auf die jeweils angegebene Weise auf Ressourcen einzuwirken:

• GET – Eine Ressource laden
• POST – Eine neue Ressource erstellen
• PUT – Eine vorhandene Ressource ändern
• DELETE – Eine Ressource entfernen

Ressourcenbezeichner

In REST-Architekturstilen kennzeichnen Ressourcenbezeichner jede Ressource, die an Client-Server-Interaktionen beteiligt ist, eindeutig.

Hypermedien

Ein „Medientyp“, also die Darstellung eines Datenformats, legt fest, wie eine Ressource verarbeitet werden soll. In REST-APIs basieren alle Medientypen auf JSON und sind Hypermedia (manchmal auch als Hypertext bezeichnet, obwohl sich die Begriffe geringfügig unterscheiden). Hypermedia bezeichnet beliebige Inhalte mit Links zu anderen Medien. Hypermedia as the Engine of Application State (HATEOAS) ist das, was die REST-Architektur einzigartig macht.

Hinweis: Laut Roy Fielding muss eine API, um als REST-API zu gelten, Hypermedia verwenden. Viele API-Designer bezeichnen ihre APIs heutzutage jedoch häufig mit dem Schlagwort „REST[ful]“, obwohl sie weder Hypermedia noch Hypertext verwenden.

Selbstbeschreibend

Ressourcenrepräsentationen sollen selbsterklärend sein, das heißt, die API vermittelt ihre Bedeutung aus ihrem eigenen Kontext heraus. Bei selbsterklärenden Repräsentationen muss der Client nicht wissen, zu welcher Kategorie eine Ressource gehört, sondern handelt anhand des mit der Ressource verknüpften Medientyps.

Vorteile von REST-APIs

Heutzutage nutzen die meisten Unternehmen intern entwickelte APIs und APIs von Drittanbietern für die Kommunikation zwischen Anwendungen, die grundlegende, innovative und geschäftskritische Funktionen bereitstellen. Bei den meisten dieser APIs handelt es sich um REST-APIs, da die von REST vorgegebenen Kommunikationsstandards einen sicheren, effizienten und zuverlässigen Informationsaustausch ermöglichen. REST-APIs können zudem mit jedem Protokoll verwendet werden.

REST-APIs sind außerdem sicher, da der RESTful-Webservice Anfragen authentifiziert, bevor eine Antwort gesendet wird. Zur Überprüfung der Benutzeridentität verwenden REST-APIs die HTTP-Authentifizierung (sowohl Basic als auch Bearer Token), API-Schlüssel und OAuth für den Anmeldezugriff.

Weitere Vorteile von REST-APIs sind:

• Systemskalierbarkeit – REST-APIs lassen sich effizient skalieren, da REST die Interaktionen zwischen Client und Server optimiert. Die RESTful-Eigenschaft der Zustandslosigkeit reduziert die Serverlast, da der Server keine Informationen aus oder über frühere Anfragen speichern muss. Darüber hinaus reduziert die Cachefähigkeit die Anzahl der Client-Server-Interaktionen, die potenziell zu Engpässen führen könnten. Das Ergebnis sind skalierbare, leistungsstarke APIs.
• Flexibilität für Entwickler – Viele Unternehmensanwendungen müssen mit internen APIs oder APIs von Drittanbietern kommunizieren. RESTful-Webservices unterstützen die Trennung von Client und Server, sodass sich beide unabhängig voneinander weiterentwickeln können.
• Technologische Unabhängigkeit – REST-APIs sind unabhängig von der Programmiersprache und dem Framework, in denen die zugehörigen Anwendungen entwickelt werden. Client- und Serveranwendungen müssen nicht dieselbe Sprache oder dasselbe Framework verwenden. Beides kann geändert werden, ohne dass sich dies auf das API-Design oder den Kommunikationsprozess auswirkt.

REST-APIs vs. GraphQL

REST ist zwar nach wie vor die beliebteste Architektur für die Verbindung von Client- und Serveranwendungen, doch GraphQL (2012 von Facebook entwickelt und 2015 als Open Source veröffentlicht) wurde als Alternative zu REST konzipiert. GraphQL-APIs sind effizienter als REST-APIs, da alle benötigten Daten mit einer einzigen Anfrage und in standardisierter Form abgerufen werden. Dennoch gibt es einige Bereiche, in denen REST seine Stärken ausspielt. GraphQL ist mit einer steilen Lernkurve verbunden und lässt sich deutlich schlechter zwischenspeichern als REST. Zudem sind Anwendungen häufig ressourcenorientiert und benötigen keine Abfragesprache wie GraphQL. Beide Modelle haben jedoch ihre Vor- und Nachteile, und Unternehmen können sich auch für den Einsatz beider Modelle entscheiden.

Wie kann NGINX helfen?

Die Flexibilität von REST-APIs ist zweifellos ein Vorteil. Zu viel Flexibilität kann jedoch auch dazu führen, dass eine potenziell langsame oder fehlerhafte API entwickelt wird. Daher entscheiden sich viele Entwickler dafür, APIs mithilfe der OpenAPI-Spezifikation zu veröffentlichen, zu verwalten und zu dokumentieren.

API Connectivity Manager, Teil der F5 NGINX Management Suite, unterstützt die OpenAPI-Spezifikation für REST-APIs. Bei der Entwicklung von API Connectivity Manager stand die Benutzerfreundlichkeit für API-Entwickler im Mittelpunkt. Es handelt sich um eine schlanke, cloudnative API-Management-Lösung mit nahtloser Integration für die Veröffentlichung von APIs im Entwicklerportal und am API-Gateway.

Starten Sie eine 30-tägige kostenlose Testversion der NGINX Management Suite, die API Connectivity Manager und Instance Manager umfasst.