REST-API: Unterschied zwischen den Versionen
(→Einheitliche Schnittstelle) |
|||
Zeile 2: | Zeile 2: | ||
== Definition und Funktionsweise == | == Definition und Funktionsweise == | ||
− | + | <html><div about="https://www.seobility.net/de/wiki/images/f/f1/Rest-API.png"><a rel="license" href="https://creativecommons.org/licenses/by-sa/4.0/"></a></html>[[File:Rest-API.png|mini|450px|rechts|alt=REST-API|'''Abbildung:''' REST-API - Autor: Seobility - Lizenz: [[Creative Commons Lizenz BY-SA 4.0|CC BY-SA 4.0]]|link=https://www.seobility.net/de/wiki/images/f/f1/Rest-API.png]]<html></div></html> | |
− | [[File:Rest-API.png|mini|450px|rechts|alt=REST-API|'''Abbildung:''' REST-API - Autor: Seobility - Lizenz: [[Creative Commons Lizenz BY-SA 4.0|CC BY-SA 4.0]]|link=https://www.seobility.net/de/wiki/images/f/f1/Rest-API.png]] | ||
<strong>API</strong> ist das Akronym für "Application Programming Interface". Dabei handelt es sich um einen Software-Intermediär, über den zwei Anwendungen im Web und auf Endgeräten miteinander kommunizieren können. Jedes Mal, wenn User eine App wie Facebook verwenden oder das Wetter auf dem Smartphone überprüfen, kommt dabei eine API zum Einsatz. | <strong>API</strong> ist das Akronym für "Application Programming Interface". Dabei handelt es sich um einen Software-Intermediär, über den zwei Anwendungen im Web und auf Endgeräten miteinander kommunizieren können. Jedes Mal, wenn User eine App wie Facebook verwenden oder das Wetter auf dem Smartphone überprüfen, kommt dabei eine API zum Einsatz. |
Version vom 28. Januar 2020, 16:13 Uhr
Inhaltsverzeichnis
Definition und Funktionsweise
API ist das Akronym für "Application Programming Interface". Dabei handelt es sich um einen Software-Intermediär, über den zwei Anwendungen im Web und auf Endgeräten miteinander kommunizieren können. Jedes Mal, wenn User eine App wie Facebook verwenden oder das Wetter auf dem Smartphone überprüfen, kommt dabei eine API zum Einsatz.
Die Abkürzung REST steht für "Representational State Transfer" und bezeichnet ein Architekturmodell. Die Architektur einer REST-API beruht auf sechs Prinzipien, die beschreiben, wie vernetzte Ressourcen im Web, beispielsweise in einer Cloud, definiert und adressiert werden. Diese Prinzipien wurden im Jahr 2000 von Roy Fielding im Rahmen seiner Dissertation "Architectural Styles and the Design of Network-based Software Architectures" beschrieben. Das Prinzip der Zustandslosigkeit ist dabei essentiell für eine REST-API. Dieses besagt, dass jede REST Nachricht alle Informationen enthält, die zum Verständnis dieser Nachricht notwendig sind. REST ist keine Programmiersprache oder grundlegende Struktur und keine Software, die ausgeführt werden kann.
RESTful APIs nutzen die in RFC 2616 definierten HTTP-Anfragemethoden GET, POST, PUT und DELETE. Damit Client und Server miteinander kommunizieren können sind für REST APIs daher keine Protokoll-Konventionen erforderlich. Mit GET werden von der RESTful API Ressourcen abgefragt. POST wird verwendet, um den Zustand einer Ressource zu aktualisieren oder zu ändern. Mit PUT können neue Ressourcen erstellt, oder der Inhalt bereits bestehender Ressourcen ersetzt werden. DELETE wird verwendet, um Ressourcen zu löschen. Diese vier HTTP-Methoden sind in der Regel ausreichend, um die meisten Anwendungsfälle abzudecken.
Ursprung und Entwicklung von REST APIs
REST ist eine Alternative zu Verfahren wie SOAP (Simple Object Access Protocol) und WSDL (Web Services Description Language). Das Architekturmodell wurde gegen Ende der 1990er Jahre entwickelt und veränderte die API-Landschaft grundlegend. Die ersten Unternehmen, die eine REST API genutzt haben, waren Ebay und Amazon. Der Zugriff auf die einfach anwendbare und gut dokumentierte eBay REST API wurde einer Auswahl von Partnern angeboten. Dadurch war der eBay Marktplatz nicht mehr nur für direkte Besucher der Ebay Plattform zugänglich, sondern über jede Website, die auf die eBay API zugriff.
Flickr startete 2004 ebenfalls eine eigene REST API, gerade rechtzeitig zu Beginn des Aufstiegs der sozialen Netzwerke und Blogs im Web. Flickr ebnete damit den Weg für Social Sharing, dem sich Facebook und Twitter später anschlossen.
Im Jahr 2006 hat Amazon mit seiner REST API zur Entwicklung der Cloud beigetragen, welche heute weit verbreitet ist. RESTful APIs ermöglichen es den Nutzern, sich mit der Cloud zu verbinden und mit den Cloud Diensten zu interagieren. Sie werden mittlerweile von vielen Websites eingesetzt und gelten als das Rückgrat des Web.
Die sechs Prinzipien der REST Architektur
Client-Server-Architektur
Das Prinzip hinter der Client-Server-Architektur liegt in der Trennung von Problemen. Die Segregation der Benutzeroberfläche von den Datenspeicherung verbessert die Portabilität der Benutzerschnittstelle über mehrere Plattformen hinweg. Für das Web ist es wichtig, dass durch die Trennung die Komponenten unabhängig voneinander entwickelt werden können.
Zustandslosigkeit
Zustandslosigkeit bedeutet, dass die Kommunikation zwischen dem Client und dem Server immer alle Informationen enthält, die zur Ausführung der Anfrage benötigt werden. Es gibt keinen Sitzungszustand auf dem Server, er wird vollständig auf der Seite des Clients gehalten. Wenn der Zugriff auf eine Ressource eine Authentifizierung erfordert, muss sich der Client bei jeder Anfrage authentifizieren.
Caching
Der Client, der Server und alle dazwischen liegenden Komponenten können alle Ressourcen zwischenspeichern, um die Leistung zu verbessern. Die Klassifizierung der Informationen als cacheable oder non-cacheable ist wählbar.
Einheitliche Schnittstelle
Damit die Komponenten einer REST API miteinander kommunizieren können, müssen sie den gleichen Regeln folgen. Dies erleichtert zudem das Verständnis der Wechselwirkungen zwischen den verschiedenen Komponenten des Systems.
Layered System
Einzelne Komponenten können nicht über die unmittelbare Ebene hinaus sehen, mit der sie interagieren. Dies bedeutet, dass ein Client, der sich mit einer Zwischenkomponente wie einem Proxy verbindet, keine Kenntnis darüber hat, was dahinter liegt. Dies ermöglicht, dass Komponenten unabhängig voneinander und somit leicht austauschbar oder erweiterbar sind.
Code-on-Demand
Zusätzlicher Code kann heruntergeladen werden, um die Client-Funktionalität zu erweitern. Dies ist jedoch optional, da der Client diesen Code möglicherweise nicht herunterladen oder ausführen kann.
Die Vorteile von REST für die Entwicklung einer API
Die vollständige Trennung der Benutzeroberfläche von Server und Datenspeicher bietet einige Vorteile für die Entwicklung einer API. So verbessert sie beispielsweise die Portabilität der Schnittstelle zu anderen Arten von Plattformen, erhöht die Skalierbarkeit der Projekte und ermöglicht es, die verschiedenen Komponenten unabhängig voneinander zu entwickeln. Entwickler können ohne Probleme auf andere Server migrieren oder Änderungen in der Datenbank vornehmen, vorausgesetzt, die Daten werden von jeder Anfrage korrekt gesendet. Die Trennung erhöht somit insgesamt die Flexibilität bei der Entwicklung.
Eine REST-API ist immer unabhängig von der Art der Plattform oder den verwendeten Sprachen, sie passt sich immer an den Typ der verwendeten Syntax oder Plattform an. Dadurch ist beim Ändern oder Testen neuer Umgebungen innerhalb einer Entwicklung eine große Freiheit gegeben. Mit einer REST-API können PHP-, Java-, Python- oder Node.js-Server verwendet werden. Nur die Antworten auf Anfragen müssen immer in der für den Informationsaustausch verwendeten Sprache, normalerweise XML oder JSON, erfolgen.
Als ein Nachteil von REST-APIs kann die fehlende Standardisierung angesehen werden, die gegebenenfalls zu Missverständnissen führen kann.