Aus dem modernen Web sind sie nicht wegzudenken: REST APIs. Dank ihnen können Websites um die Funktionen anderer Anwendungen erweitert werden. Ob du dich damit auseinandersetzen musst, wenn du nicht selbst entwickelst? Wir finden: Ja! Denn nur so hast du eine Vorstellung davon, was im Netz alles möglich ist. In diesem Artikel lernst du auch ohne jegliche Fachkenntnisse, was eine REST API ist, wie sie funktioniert, und wie sie auf modernen Webseiten zum Einsatz kommen kann.
Inhaltsverzeichnis
1. Was ist eine REST API?
Wenn du bis hierhin gelesen hast, stehen die Chancen gut, dass “REST API” für dich nur eine kryptische Buchstabenfolge darstellt. Dahinter könnte sich eigentlich alles verbergen. Eine Regierungsorganisation, eine EDM-Band, eine neue Modemarke… Um das Rätsel zu entwirren, schauen wir uns die beiden Bestandteile gesondert an. Was ist eine API? Und was macht eine API zu einer REST API?
1.1 Was bedeutet API?
Die Abkürzung API steht für Application Programming Interface, was zu Deutsch schön sperrig als Anwendungsprogrammierschnittstelle zu übersetzen ist. Dabei handelt es sich grob gesagt um eine Schnittstelle, über die zwei unterschiedliche Systeme miteinander kommunizieren. Solche Schnittstellen können überall auftreten – zwischen Programmen, Servern, selbst in Haushaltsgeräten. Im Zusammenhang mit REST wollen wir uns in diesem Artikel aber auf APIs von Webseiten und -anwendungen konzentrieren.
Du kannst dir also merken: Immer wenn Software A mit Software B kommuniziert, geschieht dies über eine Schnittstelle, also eine API. Doch wie diese Kommunikation abläuft, kann von Schnittstelle zu Schnittstelle variieren. Und genau hier kommt REST ins Spiel.
1.2 Was bedeutet REST?
Bei einer REST API handelt es sich natürlich nicht um eine übriggebliebene Schnittstelle – auch REST ist eine Abkürzung:
- Representational
- State
- Transfer
Wenn eine API eine Art Kanal darstellt, über den kommuniziert oder interagiert wird, dann bezeichnet REST die Regeln und Strukturen, nach denen dieser Austausch abgewickelt wird. Bevor wir auf diese näher eingehen, muss jedoch gesagt sein, dass der Begriff, d. h. seine Definition, heute nicht mehr klar umrissen ist.
Ins Leben gerufen wurde der Begriff von Roy Fielding in seiner Dissertation aus dem Jahre 2000 mit dem Titel “Architectural Styles and the Design of Network-based Software Architectures”. Darin entwarf er unter der Bezeichnung REST eine bestimmte “Bauweise” von Webanwendungen, die über HTTP kommunizieren. Doch seine Ausführungen lassen sich nicht problemlos auf die heutige Verwendung des Begriffs REST API übertragen. Von den fünf Gesetzen, die eine Anwendung laut Fielding einhalten muss, um als RESTful zu gelten, können nach heutigem Gebrauch ein oder zwei gebrochen werden und trotzdem wird von einer REST API gesprochen.
An dieser Stelle seien darum nur die drei wichtigsten genannt:
- Client-Server-Architektur: Der Client stellt die Anfrage an den Server, wobei beide Systeme völlig getrennt voneinander existieren und sich unabhängig weiterentwickeln können. Denke hierfür einfach daran, was passiert, wenn du z. B. www.friendventure.de in die Adresszeile deines Browsers eingibst. Als Client stellst du in Form der URL eine Anfrage an den Server, auf dem die Website gehostet wird. Dieser schickt sie dir zurück, woraufhin sie im Browser angezeigt wird.
- Statelessness: Über die Interaktion zwischen Client und Server werden keinerlei Informationen auf dem Server hinterlassen (also über den state der Interaktion). Jede Kommunikation wird auf der gleichen Grundlage ausgeführt.
- Layered System: Die Anfrage des Client kann den Server direkt erreichen, es können jedoch auch Server zwischengeschaltet sein (etwa aus Sicherheitsgründen). Welche “Schicht” der Client ansteuert, bleibt diesem verborgen.
Keine Sorge, technischer wird es nicht mehr. Es ist jedoch wichtig zu wissen, dass nicht jede Schnittstelle diesen Einschränkungen unterliegt, sondern eben nur REST APIs. Nun da geklärt wäre, was hinter der kryptischen Buchstabenfolge steckt, geht es weiter mit ihrer Funktionsweise.
2. Wie funktioniert eine REST API?
Beginnen wir mit einem bildlichen Vergleich: Eine REST API fungiert als eine Art Bote, der von einem Kunden beauftragt wird. Denke z. B. an eine Mitarbeiter:in im Postamt, der du einen Paketschein in die Hand drückst. Oder an eine Kellner:in, die deine Bestellung aufnimmt. Die Postarbeiter:in begibt sich ins Lager und holt dein Paket, die Kellner:in geht in die Küche und kommt mit deinem Essen wieder. Du (der Client) und der Server (das Postamt/Restaurant) habt nur über die Mitarbeiter:in (die REST API) kommuniziert. Du musstest weder ins Lager noch in die Küche gehen, um an den jeweiligen Inhalt zu gelangen, sondern nur einen bestimmten „Befehl“ äußern.
Von diesen Befehlen gibt es – um den bildlichen Vergleich zu verlassen – bei REST APIs vier an der Zahl: GET, PUT, POST und DELETE.
- GET: Der Client erhält vom Server die Repräsentation einer angefragten Ressource. Zum Beispiel fragt er nach den Informationen, die auf dem Server für ein bestimmtes Nutzerprofil hinterlegt wurden.
- POST: Der Client fügt dem Server eine Ressource hinzu. In diesem Fall könnte ein Client bspw. ein neues Nutzerprofil auf dem Server anlegen.
- PUT: Der Client befiehlt die Änderung einer bestehenden Ressource. Wenn das Nutzerprofil bereits vorhanden ist, erfragt der Client etwa die Änderung des Nutzernamen.
- DELETE: Der Client lässt eine Ressource auf dem Server löschen. Das Profil wird entfernt.
Gar nicht so kompliziert, oder? Zugegeben, die Analogie zur Kellner:in oder Postmitarbeiter:in schwächelt spätestens dann, wenn du sie damit beauftragst, Pakete zu vernichten oder deine Bestellung zu essen. Trotzdem solltest du nun eine gute Vorstellung davon haben, was es heißt, wenn zwei Systeme über eine REST API miteinander kommunizieren.
Im letzten Teil dieses Artikels wollen wir dir nun zeigen, zu was eine REST API in der Umsetzung gut sein kann.
3. Beispiel: Bestandskatalog auf aribas.de
Nun möchten wir dir ein konkretes Beispiel aus unseren Referenzen zeigen, dass von einer REST API profitiert: aribas.de. Das Kernstück der Website des Druckmaschinenhändlers ist der Maschinenkatalog. In ihm finden potentiellen Käufer:innen alle verfügbaren Maschinen (samt Beschreibung, Bildern und Produktdetails) und können bei Interesse Anfragen stellen.
3.1 Das Problem
Für den Relaunch der Website entschieden wir uns für eine Umsetzung auf WordPress-Basis. Diese ermöglicht eine responsive Darstellung sowie dem Kunden leichte Contentpflege. Doch der Maschinenkatalog stellte an dieser Stelle ein Problem dar. Auch wenn WordPress das mit Abstand meistgenutzte CMS auf dem Markt ist, stellt es nicht für alle Bedürfnisse immer die beste Wahl dar (dazu mehr in unserem Artikel WordPress vs. TYPO3).
Gerade für Seiten mit vielen Unterseiten/Produktseiten, stellt das ursprüngliche Blogsystem eher die zweite Wahl dar – die Pflege fällt hier schnell unübersichtlich und umständlich aus. Zwar lässt sich dies häufig mit Plug-Ins ausgleichen, doch gehen diese a) mit einem gewissen Kontrollverlust einher und b) kamen auch e-Commerce-Lösungen nicht infrage, weil Aribas die Geschäfte nicht über einen Online-Shop abwickelt. Wie kann dieses Problem gelöst werden, wenn man nicht auf WordPress als CMS verzichten möchte?
3.2 Die Lösung
Du wirst bereits erraten haben, wie die Lösung letztendlich aussah: Natürlich in Form einer REST API. Der Katalog befindet sich auf einem anderen internen Server und wird dort verwaltet. Server und Software sind auf die Pflege eines solchen Katalogs ausgerichtet. Über die REST API dieses Servers bezieht die Website nun in regelmäßigen Abständen die aktuellen Bestandsdaten.
Auf Kundenseite müssen also nur einmal Änderungen vorgenommen werden, wenn etwa eine Maschine verkauft wird, nämlich auf dem Server. Auf das Backend der Website muss nur dann zugegriffen werden, wenn der Content der Seite bearbeitet werden soll. Content Management der Seite und die Dokumentierung des Bestands sind also dank REST API zwei voneinander unabhängige Prozesse.
