Eine REST-API ist eine Art Anwendungsprogrammierschnittstelle (API), die dem REST-Modell ( Representational State Transfer ) 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 Unternehmen, mehrere Endpunkte in ihr Anwendungsökosystem zu integrieren.
Notiz: Streng genommen bezieht sich REST auf das Modell und ist kein Adjektiv zur Bezeichnung einer API, die sich daran hält. Der korrekte Begriff hierfür wäre RESTful API . Allerdings ist REST API die gebräuchlichere Verwendung und wird dementsprechend in diesem Artikel verwendet.
REST, was wie 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 Einschränkungen, die Apps und APIs einhalten müssen, um als RESTful zu gelten:
Weitere Informationen zu diesen Einschränkungen finden Sie auf Wikipedia .
Eine einheitliche Schnittstelle vereinfacht die gesamte Systemarchitektur und verbessert die Sichtbarkeit der Interaktion. Darüber hinaus gibt es spezielle Anforderungen, um sicherzustellen, dass die Informationen in standardisierter Form übertragen werden.
Vier Einschränkungen ermöglichen die Einheitlichkeit einer REST-Schnittstelle:
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 Client- und Serverkomponenten autonom weiterentwickeln. Darüber hinaus vereinfacht es die Portabilität der Client-Benutzeroberfläche über mehrere Plattformen hinweg und die Skalierbarkeit des Servers.
Im Internet findet die Client-Server-Interaktion über HTTP statt.
Bei der Client-Server-Kommunikation bedeutet Zustandslosigkeit, dass der Server keine Informationen über den Client oder die mit ihm hergestellte Sitzung speichert. Die Darstellung der sitzungsbezogenen Informationen durch den Client in jeder Nachricht muss es dem Server ermöglichen, sie isoliert und ohne Kontext aus vorherigen Nachrichten zu verstehen. Dadurch wird die Serverlast reduziert und die Leistung umfangreicher Anwendungen verbessert.
Clients müssen nicht wissen (und können es normalerweise auch nicht sagen), ob sie direkt mit dem Server oder mit einem Vermittler wie einem Reverse-Proxy oder Load Balancer verbunden sind. Zwischenserver tragen zur Verbesserung der Skalierbarkeit bei und können zur Handhabung der Sicherheit verwendet werden, sodass die Server nur für die Geschäftslogik verantwortlich sind.
HTTP-Clients und -Vermittler können Serverantworten zwischenspeichern, um die Serverlast zu verringern und die Geschwindigkeit der Datenübertragung an Endbenutzer zu erhöhen. Der Server muss angeben, ob eine Antwort zwischengespeichert werden kann oder nicht. Durch die Zwischenspeicherung wird sichergestellt, dass die Antworten auf nachfolgende Endbenutzeranforderungen richtig und aktuell (und nicht potenziell „veraltet“) sind. Da Clients auf eine Ressource über ihre URL zugreifen, bei der es sich um eine eindeutige Kennung handelt, 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, sodass der Client die Funktionalität nicht mehr selbst implementieren muss. Die Code-on-Demand-Einschränkung ist optional.
Die wichtigste Datendarstellung oder Abstraktion in REST ist eine Ressource. Eine REST-Ressource kann jede Art 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 Reihe miteinander verknüpfter Ressourcen (oder ihrem Ressourcenmodell ), die unter eindeutigen URIs zugänglich sind. Ein Client kann flexible Funktionalität 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 häufig als JSON.
Um auf die Ressourcen in der angegebenen Weise einzuwirken, werden die folgenden HTTP-Anforderungsmethoden verwendet:
In REST-Architekturstilen kennzeichnen Ressourcenkennungen eindeutig jede Ressource, die an Client-Server-Interaktionen beteiligt ist.
Ein „Medientyp“ oder eine Darstellung des Datenformats definiert, wie eine Ressource verarbeitet werden soll. In REST-APIs basieren alle Medientypen auf JSON und sind Hypermedien (manchmal auch als Hypertext bezeichnet, obwohl dies etwas anders ist). Hypermedia sind alle Inhalte mit Links zu anderen Medien. Hypermedia als Engine des Anwendungsstatus (HATEOAS) ist das, was die REST-Architektur einzigartig macht.
Notiz: Damit eine API als REST-API gilt, muss sie laut Roy Fielding Hypermedia verwenden . Allerdings bezeichnen viele API-Designer ihre APIs heutzutage häufig als Schlagwort „REST[ful]“, obwohl sie keine Hypermedien/Hypertexte verwenden.
Ressourcendarstellungen sollen selbstbeschreibend sein, was bedeutet, dass die API in ihrem eigenen Kontext verständlich ist. Bei selbstbeschreibenden Darstellungen muss der Client nicht wissen, zu welcher Kategorie eine Ressource gehört, sondern agiert stattdessen auf Grundlage des mit der Ressource verknüpften Medientyps.
Heutzutage verwenden die meisten Unternehmen für die Kommunikation zwischen Apps intern entwickelte und von Drittanbietern bereitgestellte APIs, die grundlegende, innovative und wichtige Funktionen bereitstellen. Bei der Mehrzahl dieser APIs handelt es sich um REST-APIs, da die von REST vorgeschriebenen spezifischen Kommunikationsstandards einen sicheren, effizienten und zuverlässigen Informationsaustausch ermöglichen. REST-APIs können auch mit jedem Protokoll funktionieren.
REST-APIs sind außerdem sicher, da der RESTful-Webdienst Anfragen authentifiziert, bevor eine Antwort gesendet wird. Zur Überprüfung der Benutzeridentitäten verwenden REST-APIs HTTP-Authentifizierung (sowohl Basic als auch Bearer Token ), API-Schlüssel und OAuth für den Anmeldezugriff.
Zu den weiteren Vorteilen von REST-APIs gehören:
Während REST nach wie vor die beliebteste Architektur zum Verbinden von Client- und Serveranwendungen ist, wurde GraphQL (2012 von Facebook entwickelt und 2015 als Open Source freigegeben) als Alternative zu REST konzipiert. GraphQL-APIs sind effizienter als REST-APIs, da alle benötigten Daten in einer einzigen Anfrage und in standardisierter Form angefordert werden. Dennoch gibt es einige Bereiche, in denen REST glänzt. GraphQL erfordert eine steile Lernkurve und ist weit weniger zwischenspeicherbar als REST. Darüber hinaus sind Anwendungen häufig ressourcengesteuert und erfordern keine Abfragesprache wie GraphQL. Allerdings hat jedes Modell seine Vor- und Nachteile und Unternehmen können sich für die Verwendung beider entscheiden.
Die Flexibilität von REST-APIs ist sicherlich ein Vorteil. Zu viel Flexibilität kann jedoch auch zur Entwicklung einer potenziell langsamen oder nicht funktionierenden API führen. Aus diesem Grund entscheiden sich viele Entwickler dafür, die Dokumentation von APIs mithilfe der OpenAPI-Spezifikation zu veröffentlichen, zu verwalten und zu generieren.
API Connectivity Manager , Teil der F5 NGINX Management Suite , unterstützt die OpenAPI-Spezifikation für REST-APIs. API Connectivity Manager wurde mit der Erfahrung von API-Entwicklern im Mittelpunkt entwickelt. Es handelt sich um eine leichtgewichtige, Cloud-native API-Management-Lösung mit nahtloser Integration zum Veröffentlichen von APIs im Entwicklerportal und API-Gateway.
Starten Sie eine 30-tägige kostenlose Testversion der NGINX Management Suite , die API Connectivity Manager und Instance Manager umfasst.