Eine REST-API ist eine Art von Programmierschnittstelle (API), die dem Representational State Transfer (REST)-Modell der Datendarstellung und Kommunikation zwischen zwei Systemen (einem Client und einem Server) über ein Netzwerk wie das Internet entspricht. REST-APIs unterstützen den Informationsaustausch zwischen internen und Drittanbieteranwendungen und ermöglichen es Unternehmen, mehrere Endpunkte in ihr Anwendungsökosystem zu integrieren.
Hinweis: Streng genommen bezieht sich REST auf das Modell und ist kein Adjektiv, das eine API bezeichnet und angehängt ist; der korrekte Begriff dafür ist RESTful API. Allerdings ist REST API der gebräuchlichere Begriff und wird daher in diesem Artikel verwendet.
REST, die Abkürzung für Representational State Transfer, ist ein Architekturstil, der im Jahr 2000 vom Informatiker Roy Fielding entwickelt wurde. REST bietet Entwicklern Flexibilität und ist daher ideal für die Verbindung von Anwendungen in Microservices-Architekturen.
REST definiert sechs Bedingungen, die Anwendungen und APIs erfüllen müssen, um als RESTful zu gelten:
Mehr über diese Bedingungen erfahren Sie bei Wikipedia.
Eine einheitliche Schnittstelle vereinfacht die gesamte Systemarchitektur, verbessert die Sichtbarkeit der Interaktion und stellt besondere Anforderungen, um sicherzustellen, dass die Informationen in einer einheitlichen Form übertragen werden.
Vier Bedingungen ermöglichen es, eine REST-Schnittstelle einheitlich zu gestalten:
Eine Client-Server-Architektur besteht aus Clients, Servern und Ressourcen. Durch die Trennung der Benutzeroberfläche (die vom Client gesteuert wird) von der Datenspeicherung (die vom Server gesteuert wird) können sich Client- und Server-Komponenten unabhängig voneinander entwickeln. Dies vereinfacht auch die Übertragbarkeit der Client-Benutzeroberfläche über mehrere Plattformen und die Skalierbarkeit des Servers.
Im Internet findet die Interaktion zwischen Client und Server über HTTP statt.
In 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 isoliert zu verstehen, ohne jeglichen Kontext aus früheren Nachrichten. Dies reduziert die Serverlast und verbessert die Leistung von Anwendungen mit hohem Datenvolumen.
Die Clients müssen nicht wissen (und können in der Regel auch nicht erkennen), ob sie direkt mit dem Server oder mit einem Vermittler wie einem Reverse Proxy oder Load Balancer verbunden sind. Vermittlungsserver tragen zur Verbesserung der Skalierbarkeit bei und können für die Sicherheit eingesetzt werden, sodass die Server nur für die Geschäftslogik zuständig sind.
HTTP-Clients und Vermittler können Serverantworten zwischenspeichern, um den Server zu entlasten und die Geschwindigkeit der Datenübermittlung an die Endbenutzer zu erhöhen. Der Server muss angeben, ob eine Antwort Cache-fähig ist oder nicht, wobei letzteres sicherstellt, dass die Antworten auf nachfolgende Endbenutzeranforderungen korrekt und aktuell sind (nicht möglicherweise „veraltet“). Da Clients auf eine Ressource über ihre URL zugreifen, die ein eindeutiger Bezeichner ist, kann der Client bestimmen, was auf Ressourcenebene zwischengespeichert werden soll.
Code-on-Demand bedeutet, dass der Server ausführbaren Code senden kann, um die Client-Funktionalität vorübergehend zu erweitern oder anzupassen, ohne dass der Client die Funktionalität selbst implementieren muss. Die Code-on-Demand-Bedingung ist optional.
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 zu einem nicht-digitalen Objekt. Der Zustand der Ressource zu einem bestimmten Zeitpunkt wird als Ressourcendarstellung bezeichnet.
Eine Ressourcendarstellung besteht aus drei Teilen:
Eine REST-API besteht aus einer Zusammenstellung miteinander verbundener Ressourcen (oder ihrem Ressourcenmodell), die über eindeutige URIs zugänglich sind. Ein Client kann flexible Funktionen erreichen, indem er innerhalb der Antwort auf verwandte Ressourcen und URIs verweist. Im Allgemeinen wird eine Anforderung an eine REST-API in Form einer HTTP-GET-Anforderung gesendet; Server formatieren ihre Antworten oft als JSON.
Die folgenden HTTP-Anforderungsmethoden werden verwendet, um auf Ressourcen in der angegebenen Weise zu reagieren:
In der REST-Architektur bezeichnen die Ressourcen-Bezeichner jede Ressource, die an Client-Server-Interaktionen beteiligt ist, eindeutig.
Ein „Medientyp“ oder eine Darstellung des 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, der sich jedoch von diesem Begriff leicht unterscheidet). Hypermedia ist jeder Inhalt 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 Hypermedia verwenden, um als REST-API zu gelten. Viele API-Designer bezeichnen ihre APIs heute jedoch oft als „REST[ful]“, auch wenn sie keine Hypermedia / keinen Hypertext verwenden.
Ressourcendarstellungen sollen selbstbeschreibend sein, d. h. die API muss sich in ihrem eigenen Kontext verständlich machen. Bei selbstbeschreibenden Darstellungen muss der Client nicht wissen, zu welcher Kategorie eine Ressource gehört, sondern handelt auf der Grundlage des mit der Ressource verbundenen Medientyps.
Heutzutage verwenden die meisten Unternehmen intern entwickelte APIs und APIs von Drittanbietern für die Kommunikation zwischen Anwendungen, die grundlegende, innovative und kritische Funktionen bereitstellen. Bei den meisten dieser APIs handelt es sich um REST-APIs, da die spezifischen Kommunikationsstandards, die von REST vorgegeben werden, einen sicheren, effizienten und zuverlässigen Informationsaustausch ermöglichen. REST-APIs können außerdem mit jedem Protokoll arbeiten.
REST-APIs sind auch deshalb sicher, weil der RESTful-Webdienst Anforderungen authentifiziert, bevor eine Antwort gesendet wird. Um Benutzeridentitäten zu überprüfen, verwenden REST-APIs HTTP-Authentifizierung (sowohl Basic als auch Bearer-Token), API-Schlüssel und OAuth für den Anmeldezugriff.
Weitere Vorteile von REST-APIs sind:
Während REST nach wie vor die beliebteste Architektur für die Verbindung von Client- und Serveranwendungen ist, wurde GraphQL (2012 von Facebook entwickelt und 2015 freigegeben) als Alternative zu REST konzipiert. GraphQL-APIs sind effizienter als REST-APIs, da alle benötigten Daten in einer einzigen Anforderung und in standardisierter Form angefordert werden, aber es gibt immer noch einige Bereiche, in denen REST glänzt. GraphQL erfordert eine steile Lernkurve und ist weit weniger Cache-fähig als REST. Außerdem werden Anwendungen oft von Ressourcen gesteuert und benötigen keine Abfragesprache wie GraphQL. Dennoch hat jedes Modell seine Vor- und Nachteile, und Organisationen können sich für die Verwendung beider entscheiden.
Die Flexibilität von REST-APIs ist sicherlich ein Vorteil, aber zu viel Flexibilität kann auch dazu führen, dass man eine potenziell langsame oder fehlerhafte API entwirft, weshalb sich viele Entwickler dafür entscheiden, APIs mithilfe der OpenAPI-Spezifikation zu veröffentlichen, zu verwalten und zu dokumentieren.
Der API Connectivity Manager, Teil der F5 NGINX Management Suite, unterstützt die OpenAPI-Spezifikation für REST-APIs. Der API Connectivity Manager wurde mit Blick auf die Erfahrung von API-Entwicklern entworfen. Es handelt sich um eine leichtgewichtige, Cloud-native API-Verwaltungslösung mit nahtloser Integration für die Veröffentlichung von APIs auf dem Entwicklerportal und API-Gateway.
Starten Sie eine kostenlose 30-Tage-Testversion der NGINX Management Suite, die den API Connectivity Manager und den Instance Manager umfasst.