REST-API

Programme müssen sich oft gegenseitig Daten liefern. Eine Wetter-App auf dem Handy hat die Wetterdaten nicht selbst gespeichert. Sie fragt einen fremden Computer im Internet danach und bekommt sie geschickt. Damit das klappt, brauchen beide Seiten feste Regeln: Wie muss die Frage aussehen, und in welcher Form kommt die Antwort? Eine REST-API ist so ein Regelwerk. Das Besondere daran: Sie benutzt genau die Technik, mit der auch ein Webbrowser Seiten lädt, nämlich Adressen im Netz und einfache Befehle wie „hole“ oder „speichere“.

Warum fast jede App eine REST-API im Rücken hat

REST hat sich durchgesetzt, weil es die vorhandene Technik des Webs weiterverwendet. Vor REST gab es kompliziertere Verfahren, bei denen Programme lange Nachrichten in einem starren Format austauschten. REST kommt mit dem aus, was ohnehin jeder Server und jede Programmiersprache beherrscht. Ein Entwickler kann eine REST-Schnittstelle oft in wenigen Minuten ausprobieren, indem er die Adresse einfach in den Browser tippt.

Für Unternehmen ist das ein wirtschaftlicher Punkt. Wer eine REST-API anbietet, macht seine Daten für fremde Entwickler nutzbar, ohne den eigenen Programmcode herauszugeben. Google, die Deutsche Bahn oder Zahlungsdienstleister verdienen Geld damit, dass andere Firmen ihre Schnittstellen benutzen. Manche Anbieter rechnen pro Anfrage ab, andere verkaufen Pakete mit einer festen Zahl an Abrufen pro Monat.

Auch innerhalb einer einzigen Firma sind REST-APIs üblich. Große Software wird heute in viele kleine Einzelprogramme zerlegt, die über solche Schnittstellen miteinander reden. Der Vorteil: Jedes Teilstück kann eigenständig weiterentwickelt oder ausgetauscht werden, solange die Schnittstelle gleich bleibt.

Adressen, Befehle und die Antwort in JSON

Jede Information hat bei REST eine eigene Adresse, eine sogenannte URL. Ein Beispiel: Unter der Adresse eines Onlineshops könnte /kunden/4711 der Kunde mit der Nummer 4711 stehen. Diese Adressen zeigen auf Dinge, nicht auf Tätigkeiten. Was mit dem Ding passieren soll, sagt ein zusätzlicher Befehl.

Davon gibt es im Kern vier. GET holt Daten ab, POST legt etwas Neues an, PUT ändert einen bestehenden Eintrag, DELETE löscht ihn. Damit lässt sich fast alles abdecken, was eine Anwendung mit Daten anstellen muss. Die Antwort kommt meist in einem Format namens JSON zurück, einer Textschreibweise, die für Menschen noch lesbar und für Programme leicht auswertbar ist. Zusätzlich schickt der Server eine Zahl mit, den Statuscode. Die 200 bedeutet „alles in Ordnung“, die berühmte 404 heißt „nicht gefunden“.

Ein wichtiges Prinzip heißt Zustandslosigkeit. Der Server merkt sich zwischen zwei Anfragen nichts über den Anfragenden. Jede Anfrage muss alle nötigen Angaben selbst enthalten, auch den Nachweis, wer man ist. Das wirkt umständlich, hat aber einen praktischen Grund: Man kann beliebig viele Server nebeneinanderstellen, und es ist egal, welcher davon die nächste Anfrage bearbeitet. Genau das macht große Dienste erst skalierbar.

REST im Alltag und in KI-Produkten

Man benutzt REST-APIs ständig, ohne es zu bemerken. Der Fahrplan in der Bahn-App, die Karte in einer Lieferdienst-App, die Kurse in einer Börsen-App: Dahinter stecken fast immer solche Abrufe. Auch wenn im Onlineshop während des Bezahlens kurz ein Ladekreis erscheint, spricht die Seite gerade mit der Schnittstelle eines Zahlungsdienstleisters.

In der KI-Branche sind REST-APIs der übliche Weg, ein Sprachmodell zu benutzen. Wer ChatGPT oder ein ähnliches Modell in die eigene Software einbauen will, schickt den Text per POST an eine Adresse des Anbieters und bekommt die Antwort als JSON zurück. Abgerechnet wird nach Textmenge. Wenn in Nachrichten steht, ein Unternehmen habe „KI integriert“, steckt dahinter meist genau das.

Zwei Abgrenzungen sind nützlich. Eine API ist der Oberbegriff für jede Programmschnittstelle, REST ist nur ein bestimmter Stil davon. Und es gibt Alternativen: GraphQL lässt den Anfragenden genauer bestimmen, welche Felder er braucht, gRPC ist schneller, aber schwerer zu durchschauen. Ein verbreiteter Irrtum ist außerdem, REST sei ein festes Protokoll mit Zertifikat. Es ist nur eine Sammlung von Empfehlungen, und viele Schnittstellen, die sich REST nennen, halten sich nur teilweise daran.