Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Was ist REST?
Auf einer hohen Ebene ist Representational State Transfer (REST) eine Softwarearchitektur, die Bedingungen für die Funktionsweise einer API festlegt. REST wurde ursprünglich als Richtlinie für die Verwaltung der Kommunikation in einem komplexen Netzwerk wie dem Internet entwickelt. Sie können die REST-based Architektur verwenden, um eine leistungsstarke und zuverlässige Kommunikation in großem Maßstab zu unterstützen. Sie können sie einfach implementieren und ändern, um jedem API-System Transparenz und plattformübergreifende Portabilität zu bieten.
API-Entwickler können APIs mithilfe verschiedener Architekturen entwerfen. APIs, die dem REST-Architekturstil folgen, werden als REST-APIs bezeichnet. Webdienste, die die REST-Architektur implementieren, werden als RESTful-Webdienste bezeichnet. Der Begriff RESTful-API bezieht sich im Allgemeinen auf RESTful-Web-APIs. Sie können die Begriffe REST-API und RESTful-API jedoch synonym verwenden.
Im Folgenden sind einige der Prinzipien des REST-Architekturstils aufgeführt:
Einheitliche Oberfläche
Die einheitliche Oberfläche ist grundlegend für das Design jedes RESTful-Webservices. Es zeigt an, dass der Server Informationen in einem Standardformat überträgt. Die formatierte Ressource wird in REST als Repräsentation bezeichnet. Dieses Format kann sich von der internen Darstellung der Ressource in der Serveranwendung unterscheiden. Beispielsweise kann der Server Daten als Text speichern, sie jedoch in einem HTML-Darstellungsformat senden.
Eine einheitliche Oberfläche setzt vier architektonische Einschränkungen voraus:
-
Anfragen sollten Ressourcen identifizieren. Sie tun dies, indem sie eine einheitliche Ressourcenkennung verwenden.
-
Die Ressourcendarstellung enthält genügend Informationen, um die Ressource bei Bedarf ändern oder löschen zu können. Der Server erfüllt diese Bedingung, indem er Metadaten sendet, die die Ressource näher beschreiben.
-
Die Clients erhalten Informationen darüber, wie die Repräsentation weiter verarbeitet werden kann. Der Server erreicht dies, indem er selbstbeschreibende Nachrichten sendet, die Metadaten darüber enthalten, wie der Client sie am besten nutzen kann.
-
Die Clients erhalten Informationen über alle anderen Ressourcen, die sie zum Erledigen einer Aufgabe benötigen. Der Server erreicht dies, indem er Hyperlinks in der Darstellung sendet, sodass die Clients dynamisch mehr Ressourcen ermitteln können.
Staatenlosigkeit
In der REST-Architektur bezieht sich Zustandslosigkeit auf eine Kommunikationsmethode, bei der der Server jede Client-Anfrage unabhängig von allen vorherigen Anfragen abschließt. Clients können Ressourcen in beliebiger Reihenfolge anfordern, und jede Anfrage ist zustandslos oder von anderen Anfragen isoliert. Diese Einschränkung des REST-API-Designs impliziert, dass der Server die Anfrage jedes Mal vollständig verstehen und erfüllen kann.
Mehrschichtiges System
In einer mehrschichtigen Systemarchitektur kann der Client eine Verbindung zu anderen autorisierten Vermittlern zwischen dem Client und dem Server herstellen, und er erhält trotzdem Antworten vom Server. Server können Anfragen auch an andere Server weiterleiten. Sie können Ihren RESTful-Webservice so gestalten, dass er auf mehreren Servern mit mehreren Ebenen wie Sicherheits-, Anwendungs- und Geschäftslogik ausgeführt wird und bei der Erfüllung von Kundenanforderungen zusammenarbeiten. Diese Ebenen bleiben für den Client unsichtbar.
Cachefähigkeit
RESTful-Webdienste unterstützen Caching. Dabei werden einige Antworten auf dem Client oder einem Vermittler gespeichert, um die Antwortzeit des Servers zu verbessern. Nehmen wir zum Beispiel an, Sie besuchen eine Website, die auf jeder Seite gemeinsame Kopf- und Fußzeilenbilder hat. Jedes Mal, wenn Sie eine neue Webseitenseite besuchen, muss der Server dieselben Bilder erneut senden. Um dies zu vermeiden, speichert oder speichert der Client diese Bilder nach der ersten Antwort und verwendet dann die Bilder direkt aus dem Cache. RESTful-Webdienste steuern das Caching, indem sie API-Antworten verwenden, die sich selbst als zwischenspeicherbar oder nicht zwischenspeicherbar definieren.
Was ist eine RESTful-API?
Die RESTful-API ist eine Schnittstelle, die zwei Computersysteme verwenden, um Informationen sicher über das Internet auszutauschen. Die meisten Geschäftsanwendungen müssen mit anderen internen Anwendungen und Anwendungen von Drittanbietern kommunizieren, um verschiedene Aufgaben ausführen zu können. Um beispielsweise monatliche Gehaltsabrechnungen zu erstellen, muss Ihr internes Buchhaltungssystem Daten mit dem Banksystem Ihres Kunden teilen, um die Rechnungsstellung zu automatisieren und mit einer internen Arbeitszeittabellen-Anwendung zu kommunizieren. RESTful-APIs unterstützen diesen Informationsaustausch, da sie sicheren, zuverlässigen und effizienten Softwarekommunikationsstandards folgen.
Wie funktionieren RESTful-APIs?
Die Grundfunktion einer RESTful-API ist dieselbe wie beim Surfen im Internet. Der Client kontaktiert den Server mithilfe der API, wenn er eine Ressource benötigt. API-Entwickler erklären in der API-Dokumentation der Serveranwendung, wie der Client die REST-API verwenden sollte. Dies sind die allgemeinen Schritte für jeden REST-API-Aufruf:
-
Der Client sendet eine Anfrage an den Server. Der Client folgt der API-Dokumentation, um die Anfrage so zu formatieren, dass der Server sie versteht.
-
Der Server authentifiziert den Client und bestätigt, dass der Client das Recht hat, diese Anfrage zu stellen.
-
Der Server empfängt die Anfrage und verarbeitet sie intern.
-
Der Server gibt eine Antwort an den Client zurück. Die Antwort enthält Informationen, die dem Client mitteilen, ob die Anfrage erfolgreich war. Die Antwort enthält auch alle Informationen, die der Client angefordert hat.
Die Details der REST-API-Anfrage und -Antwort variieren geringfügig, je nachdem, wie die API-Entwickler die API entwerfen.
