{"id":31684,"date":"2024-11-12T12:39:28","date_gmt":"2024-11-12T12:39:28","guid":{"rendered":"https:\/\/www.seobility.net\/?post_type=wiki&p=31684"},"modified":"2025-03-21T16:33:31","modified_gmt":"2025-03-21T16:33:31","slug":"REST-API","status":"publish","type":"wiki","link":"https:\/\/www.seobility.net\/de\/wiki\/REST-API","title":{"rendered":"REST-API"},"content":{"rendered":"

Definition und Funktionsweise<\/span><\/h2>\n
\n
\"REST-API\"<\/a> <\/p>\n
Abbildung:<\/b> REST-API – Autor: Seobility – Lizenz: CC BY-SA 4.0<\/a><\/div>\n<\/div>\n<\/div>\n

API<\/strong> ist das Akronym f\u00fcr „Application Programming Interface“. Dabei handelt es sich um einen Software-Intermedi\u00e4r, \u00fcber den zwei Anwendungen im Web und auf Endger\u00e4ten miteinander kommunizieren k\u00f6nnen. Jedes Mal, wenn User eine App wie Facebook verwenden oder das Wetter auf dem Smartphone \u00fcberpr\u00fcfen, kommt dabei eine API zum Einsatz.\n<\/p>\n

Die Abk\u00fcrzung REST steht f\u00fcr „Representational State Transfer“ und bezeichnet ein Architekturmodell. Die Architektur einer REST-API<\/strong> beruht auf sechs Prinzipien<\/a>, 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\u00fcr eine REST-API. Dieses besagt, dass jede REST Nachricht alle Informationen enth\u00e4lt, die zum Verst\u00e4ndnis dieser Nachricht notwendig sind. REST ist keine Programmiersprache oder grundlegende Struktur und keine Software, die ausgef\u00fchrt werden kann.\n<\/p>\n

RESTful APIs nutzen die in RFC 2616<\/a> definierten HTTP-Anfragemethoden GET, POST, PUT und DELETE. Damit Client und Server miteinander kommunizieren k\u00f6nnen sind f\u00fcr 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 \u00e4ndern. Mit PUT k\u00f6nnen neue Ressourcen erstellt, oder der Inhalt bereits bestehender Ressourcen ersetzt werden. DELETE wird verwendet, um Ressourcen zu l\u00f6schen. Diese vier HTTP-Methoden sind in der Regel ausreichend, um die meisten Anwendungsf\u00e4lle abzudecken.\n<\/p>\n

Ursprung und Entwicklung von REST APIs<\/span><\/h2>\n

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\u00e4nderte 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\u00fcr direkte Besucher der Ebay Plattform zug\u00e4nglich, sondern \u00fcber jede Website, die auf die eBay API zugriff.\n<\/p>\n

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\u00fcr Social Sharing<\/a>, dem sich Facebook und Twitter sp\u00e4ter anschlossen.\n<\/p>\n

Im Jahr 2006 hat Amazon mit seiner REST API zur Entwicklung der Cloud beigetragen, welche heute weit verbreitet ist. RESTful APIs erm\u00f6glichen 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\u00fcckgrat des Web.\n<\/p>\n

Die sechs Prinzipien der REST Architektur<\/span><\/h2>\n

Client-Server-Architektur<\/span><\/h3>\n

Das Prinzip hinter der Client-Server-Architektur liegt in der Trennung von Problemen. Die Segregation der Benutzeroberfl\u00e4che von den Datenspeicherung verbessert die Portabilit\u00e4t der Benutzerschnittstelle \u00fcber mehrere Plattformen hinweg. F\u00fcr das Web ist es wichtig, dass durch die Trennung die Komponenten unabh\u00e4ngig voneinander entwickelt werden k\u00f6nnen.\n<\/p>\n

Zustandslosigkeit<\/span><\/h3>\n

Zustandslosigkeit bedeutet, dass die Kommunikation zwischen dem Client und dem Server immer alle Informationen enth\u00e4lt, die zur Ausf\u00fchrung der Anfrage ben\u00f6tigt werden. Es gibt keinen Sitzungszustand auf dem Server, er wird vollst\u00e4ndig auf der Seite des Clients gehalten. Wenn der Zugriff auf eine Ressource eine Authentifizierung erfordert, muss sich der Client bei jeder Anfrage authentifizieren.\n<\/p>\n

Caching<\/a><\/span><\/h3>\n

Der Client, der Server und alle dazwischen liegenden Komponenten k\u00f6nnen alle Ressourcen zwischenspeichern, um die Leistung zu verbessern. Die Klassifizierung der Informationen als cacheable oder non-cacheable ist w\u00e4hlbar.\n<\/p>\n

Einheitliche Schnittstelle<\/span><\/h3>\n

Damit die Komponenten einer REST API miteinander kommunizieren k\u00f6nnen, m\u00fcssen sie den gleichen Regeln folgen. Dies erleichtert zudem das Verst\u00e4ndnis der Wechselwirkungen zwischen den verschiedenen Komponenten des Systems.\n<\/p>\n

Layered System<\/span><\/h3>\n

Einzelne Komponenten k\u00f6nnen nicht \u00fcber die unmittelbare Ebene hinaus sehen, mit der sie interagieren. Dies bedeutet, dass ein Client, der sich mit einer Zwischenkomponente wie einem Proxy<\/a> verbindet, keine Kenntnis dar\u00fcber hat, was dahinter liegt. Dies erm\u00f6glicht, dass Komponenten unabh\u00e4ngig voneinander und somit leicht austauschbar oder erweiterbar sind.\n<\/p>\n

Code-on-Demand<\/span><\/h3>\n

Zus\u00e4tzlicher Code kann heruntergeladen werden, um die Client-Funktionalit\u00e4t zu erweitern. Dies ist jedoch optional, da der Client diesen Code m\u00f6glicherweise nicht herunterladen oder ausf\u00fchren kann.\n<\/p>\n

Die Vorteile von REST f\u00fcr die Entwicklung einer API<\/span><\/h2>\n

Die vollst\u00e4ndige Trennung der Benutzeroberfl\u00e4che von Server und Datenspeicher bietet einige Vorteile f\u00fcr die Entwicklung einer API. So verbessert sie beispielsweise die Portabilit\u00e4t der Schnittstelle zu anderen Arten von Plattformen, erh\u00f6ht die Skalierbarkeit der Projekte und erm\u00f6glicht es, die verschiedenen Komponenten unabh\u00e4ngig voneinander zu entwickeln. Entwickler k\u00f6nnen ohne Probleme auf andere Server migrieren oder \u00c4nderungen in der Datenbank vornehmen, vorausgesetzt, die Daten werden von jeder Anfrage korrekt gesendet. Die Trennung erh\u00f6ht somit insgesamt die Flexibilit\u00e4t bei der Entwicklung.\n<\/p>\n

Eine REST-API ist immer unabh\u00e4ngig von der Art der Plattform oder den verwendeten Sprachen, sie passt sich immer an den Typ der verwendeten Syntax<\/a> oder Plattform an. Dadurch ist beim \u00c4ndern oder Testen neuer Umgebungen innerhalb einer Entwicklung eine gro\u00dfe Freiheit gegeben. Mit einer REST-API k\u00f6nnen PHP-, Java-, Python- oder Node.js-Server verwendet werden. Nur die Antworten auf Anfragen m\u00fcssen immer in der f\u00fcr den Informationsaustausch verwendeten Sprache, normalerweise XML oder JSON, erfolgen.\n<\/p>\n

Als ein Nachteil von REST-APIs kann die fehlende Standardisierung angesehen werden, die gegebenenfalls zu Missverst\u00e4ndnissen f\u00fchren kann.\n<\/p>\n

Weiterf\u00fchrende Links<\/span><\/h2>\n