REST-API: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „== Definition und Funktionsweise == <strong>API</strong> ist das Akronym für "Application Programming Interface". Dabei handelt es sich um einen Software-Int…“) |
(→Weiterführende Links) |
||
| (13 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| + | <seo title="Was ist eine REST API? Definition und Erklärung" metadescription="Bei API handelt es sich um einen Software-Intermediär, über den zwei Anwendungen miteinander kommunizieren können. Jetzt weiterlesen ..." /> | ||
| + | |||
== Definition und Funktionsweise == | == Definition und Funktionsweise == | ||
| + | [[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. | ||
| − | Die Abkürzung REST steht für "Representational State Transfer" und bezeichnet ein Architekturmodell. Die Architektur einer <strong>REST-API</strong> beruht auf [# | + | Die Abkürzung REST steht für "Representational State Transfer" und bezeichnet ein Architekturmodell. Die Architektur einer <strong>REST-API</strong> beruht auf [[#Die sechs Prinzipien der REST Architektur|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 ausreichend, um die meisten Anwendungsfälle abzudecken. | + | 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 == | == Ursprung und Entwicklung von REST APIs == | ||
| − | REST ist eine Alternative zu SOAP (Simple Object Access Protocol) und | + | 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. | 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. | ||
| Zeile 25: | Zeile 28: | ||
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. | 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 === | + | === [[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. | + | 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 === | === Einheitliche Schnittstelle === | ||
| − | Damit die | + | 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 === | === 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. | + | 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-Server|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 === | === Code-on-Demand === | ||
| Zeile 45: | Zeile 48: | ||
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. | 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. | + | 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. | Als ein Nachteil von REST-APIs kann die fehlende Standardisierung angesehen werden, die gegebenenfalls zu Missverständnissen führen kann. | ||
| Zeile 54: | Zeile 57: | ||
[[Kategorie:Web Entwicklung]] | [[Kategorie:Web Entwicklung]] | ||
| + | |||
| + | <html><script type="application/ld+json"> | ||
| + | { | ||
| + | "@context": "https://schema.org/", | ||
| + | "@type": "ImageObject", | ||
| + | "contentUrl": "https://www.seobility.net/de/wiki/images/f/f1/Rest-API.png", | ||
| + | "license": "https://creativecommons.org/licenses/by-sa/4.0/deed.de", | ||
| + | "acquireLicensePage": "https://www.seobility.net/de/wiki/Creative_Commons_Lizenz_BY-SA_4.0" | ||
| + | } | ||
| + | </script></html> | ||
| + | |||
| + | {| class="wikitable" style="text-align:left" | ||
| + | |- | ||
| + | |'''Über den Autor''' | ||
| + | |- | ||
| + | | [[File:Seobility S.jpg|link=|100px|left|alt=Seobility S]] Das Seobility Wiki Team besteht aus SEO-, Online-Marketing- und Web-Experten mit praktischer Erfahrung in den Bereichen Suchmaschinenoptimierung, Online-Marketing und Webentwicklung. Alle unsere Artikel durchlaufen einen mehrstufigen Redaktionsprozess, um Dir die bestmögliche Qualität und wirklich hilfreiche Informationen bieten zu können. <html><a href="https://www.seobility.net/de/wiki/Seobility_Wiki_Team" target="_blank">Mehr Informationen über das Seobility Wiki Team</a></html>. | ||
| + | |} | ||
| + | |||
| + | <html><script type="application/ld+json"> | ||
| + | { | ||
| + | "@context": "https://schema.org", | ||
| + | "@type": "Article", | ||
| + | "author": { | ||
| + | "@type": "Organization", | ||
| + | "name": "Seobility", | ||
| + | "url": "https://www.seobility.net/" | ||
| + | } | ||
| + | } | ||
| + | </script></html> | ||
Aktuelle Version vom 23. Januar 2024, 16:51 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.
Weiterführende Links
| Über den Autor |
 |