REST-API

Was ist eine REST-API?

Eine REST-API ist eine Programmierschnittstelle, über die Anwendungen Daten und Funktionen über HTTP austauschen. Ressourcen werden durch URLs adressiert und mit Methoden wie GET, POST, PUT oder DELETE verarbeitet. REST-APIs arbeiten zustandslos und übertragen Daten häufig im JSON-Format, sind jedoch weder an JSON noch an HTTP zwingend gebunden.

Eine REST-API verbindet Softwarekomponenten über klar definierte Anfragen und Antworten. Die deutsche Bezeichnung REST-Schnittstelle beschreibt dasselbe Konzept. REST steht für Representational State Transfer und bezeichnet einen Architekturstil, den Roy Fielding im Jahr 2000 in seiner Dissertation formulierte.

Wie funktioniert eine REST-API?

Eine REST-API behandelt Informationen als Ressourcen. Ein Onlineshop kann beispielsweise Produkte, Kategorien, Bestellungen und Kunden als getrennte Ressourcen bereitstellen. Die Adresse /produkte/42 verweist dabei auf das Produkt mit der Kennung 42. Welche Aktion ausgeführt wird, bestimmt in der Regel die verwendete HTTP-Methode.

HTTP-Methode	Typischer Zweck	Beispiel
GET	Ressource abrufen	`GET /produkte/42`
POST	Neue Ressource anlegen	`POST /produkte`
PUT	Ressource vollständig ersetzen	`PUT /produkte/42`
PATCH	Ressource teilweise ändern	`PATCH /produkte/42`
DELETE	Ressource entfernen	`DELETE /produkte/42`

Die REST-API sendet zu jeder Anfrage einen HTTP-Statuscode. Ein Code aus der Gruppe 200 signalisiert eine erfolgreiche Verarbeitung. 201 steht typischerweise für eine neu angelegte Ressource, 400 für eine fehlerhafte Anfrage, 401 für eine fehlende oder ungültige Anmeldung, 404 für eine nicht gefundene Ressource und 500 für einen serverseitigen Fehler.

Eine Anfrage an GET /produkte/42 kann den Statuscode 200 und ein JSON-Objekt mit Name, Preis und Verfügbarkeit zurückgeben. Existiert das Produkt nicht, sollte dieselbe Adresse den Statuscode 404 liefern. Der Statuscode beschreibt das Ergebnis der Anfrage, während der Antwortkörper die dazugehörigen Daten oder eine Fehlermeldung enthält.

Merkmale einer REST-API

Eine REST-API gilt nur dann als REST-konform, wenn sie mehrere Architekturbedingungen erfüllt. Eine HTTP-Schnittstelle mit JSON-Ausgabe ist deshalb nicht automatisch eine REST-API. Maßgeblich sind die Struktur der Kommunikation und der Umgang mit Ressourcen.

Client-Server-Trennung: Benutzeroberfläche und Datenverarbeitung werden unabhängig voneinander entwickelt.
Zustandslosigkeit: Jede Anfrage enthält alle Informationen, die der Server zur Verarbeitung benötigt.
Einheitliche Schnittstelle: Ressourcen werden konsistent adressiert und mit standardisierten Operationen verarbeitet.
Cache-Fähigkeit: Antworten kennzeichnen, ob sie zwischengespeichert und erneut verwendet werden dürfen.
Schichtenarchitektur: Proxys, Gateways oder Lastverteiler können zwischen Client und Server liegen.
Code on Demand: Der Server darf ausführbaren Code übertragen. Diese Bedingung ist optional.

Zustandslos bedeutet nicht, dass eine REST-API keine Benutzerdaten oder Sitzungen verwalten darf. Der Server darf Daten dauerhaft speichern. Er soll jedoch keinen versteckten Sitzungszustand benötigen, um eine einzelne Anfrage zu verstehen. Ein Zugriffstoken muss deshalb bei jeder geschützten Anfrage erneut übermittelt werden.

REST-API und Datenformate

JSON ist das häufigste Datenformat moderner REST-APIs, weil sich die kompakte Struktur in vielen Programmiersprachen direkt verarbeiten lässt. REST schreibt JSON jedoch nicht vor. Eine REST-API kann ebenso XML, CSV, HTML, Bilder oder andere Repräsentationen einer Ressource ausliefern.

Der Client kann über den HTTP-Header Accept angeben, welches Antwortformat er verarbeiten kann. Der Header Content-Type beschreibt das Format der gesendeten oder empfangenen Daten. Unterstützt eine REST-API mehrere Repräsentationen, kann dieselbe Ressource je nach Anfrage beispielsweise als JSON oder XML ausgegeben werden.

REST-API in der Webentwicklung

In der Webentwicklung trennt eine REST-API das Frontend von Backend, Datenbank und externen Diensten. Eine Website, mobile App und interne Verwaltungsoberfläche können dadurch dieselben Produkt- oder Kundendaten verwenden. Änderungen an der Benutzeroberfläche erfordern nicht automatisch eine Anpassung der Datenhaltung, solange der vereinbarte API-Vertrag stabil bleibt.

Bei einem Headless-CMS liefert die REST-API Inhalte unabhängig vom späteren Ausgabekanal. Dieselben Produktinformationen können auf einer Website, in einer App oder auf einem digitalen Verkaufsterminal erscheinen. Bei der Planung eines solchen Systems sollten API-Struktur, interne Verlinkung, serverseitiges Rendering und Ladezeiten bereits im Webdesign-Konzept berücksichtigt werden.

REST-API für SEO, SEA und GEO

Eine REST-API wirkt sich auf SEO aus, wenn Inhalte erst nachträglich im Browser geladen werden. Suchmaschinen können JavaScript verarbeiten, eine serverseitig ausgelieferte HTML-Version reduziert jedoch die Abhängigkeit vom späteren Rendering. Ein technisches SEO-Audit sollte deshalb prüfen, ob Seitentitel, Überschriften, interne Links und Hauptinhalte bereits im initialen HTML vorhanden sind.

Für SEA liefert eine REST-API beispielsweise Produktpreise, Lagerbestände oder Conversion-Daten an Kampagnensysteme. Für GEO, also Generative Engine Optimization, können strukturierte Schnittstellen Inhalte für interne Anwendungen und KI-Prozesse bereitstellen. Eine öffentlich erreichbare REST-API führt allerdings nicht automatisch dazu, dass ChatGPT, Perplexity, Gemini oder Grok die Daten abrufen oder als Quelle nennen. Dafür benötigt eine Domain weiterhin zugängliche, verständliche und zitierfähige Webinhalte, wie sie auch bei einer Optimierung für KI-Suchen betrachtet werden.

Messbar ist eine REST-API anhand von Antwortzeit, Verfügbarkeit, Fehlerrate und Anzahl der Anfragen. Eine Fehlerrate lässt sich als Zahl der fehlgeschlagenen Anfragen geteilt durch alle Anfragen, multipliziert mit 100, berechnen. Bei 50 Fehlern unter 10.000 Anfragen beträgt sie 0,5 Prozent. Marketingplattformen wie die Performance Suite nutzen APIs, um Daten aus verschiedenen Bereichen in einem System zusammenzuführen.

REST-API, SOAP und GraphQL

Der Unterschied zwischen REST-API und SOAP liegt zunächst in der technischen Einordnung. REST ist ein Architekturstil, SOAP ein standardisiertes Nachrichtenprotokoll. SOAP verwendet XML und definiert formale Regeln für Nachrichten, Fehler und Erweiterungen. Eine REST-API kann unterschiedliche Datenformate verwenden und orientiert sich häufig direkt an den Mechanismen von HTTP.

Der Unterschied zwischen REST-API und GraphQL liegt vor allem in der Datenabfrage. Bei REST stellt der Server mehrere Ressourcenadressen bereit und bestimmt die Struktur der jeweiligen Antworten. Bei GraphQL sendet der Client eine Abfrage an einen zentralen Endpunkt und benennt die benötigten Felder. GraphQL kann dadurch Unterabfragen reduzieren, verlangt jedoch eine andere Caching-, Sicherheits- und Berechtigungslogik.

Sicherheit und typische Fehler

Eine REST-API sollte ausschließlich verschlüsselt über HTTPS erreichbar sein. Geschützte Ressourcen benötigen eine Authentifizierung, beispielsweise über kurzlebige Zugriffstoken. Berechtigungen müssen serverseitig für jede Ressource geprüft werden, da eine gültige Anmeldung allein noch keinen Zugriff auf beliebige Kunden, Bestellungen oder Dokumente erlaubt.

Fehlende Begrenzungen ermöglichen sehr große Abfragen und belasten Server sowie Datenbanken.
Unklare Statuscodes erschweren Clients die Unterscheidung zwischen Eingabe-, Zugriffs- und Serverfehlern.
Unversionierte Änderungen können bestehende Websites, Apps und Datenimporte unerwartet beschädigen.
Personenbezogene oder interne Felder gelangen in Antworten, obwohl der Client sie nicht benötigt.
Eine lückenhafte Dokumentation lässt Parameter, Antwortformate und Fehlerfälle offen.

GET, PUT und DELETE sind nach HTTP-Semantik idempotent. Mehrere identische Anfragen sollen denselben beabsichtigten Zustand erzeugen wie eine einzelne Anfrage. POST ist grundsätzlich nicht idempotent und kann bei einer Wiederholung mehrere Datensätze anlegen. Bei Bestellungen oder Zahlungen verhindern Idempotenzschlüssel, dass ein abgebrochener und erneut gesendeter Aufruf dieselbe Transaktion doppelt ausführt.

Häufige Fragen zur REST-API

Wofür braucht man eine REST-API?

Eine REST-API verbindet Websites, Apps, Datenbanken und externe Dienste über definierte Anfragen. Typische Anwendungen sind Produktimporte, Zahlungsprozesse, CRM-Anbindungen, mobile Apps und die Übertragung von Marketingdaten.

Ist jede HTTP-API eine REST-API?

Nein. Eine HTTP-API wird erst durch Bedingungen wie Zustandslosigkeit, Ressourcenorientierung, Cache-Fähigkeit und eine einheitliche Schnittstelle zu einer REST-API. Eine JSON-Ausgabe allein reicht dafür nicht aus.

Kann eine REST-API ohne JSON arbeiten?

Ja. REST legt kein bestimmtes Datenformat fest. Eine REST-API kann unter anderem JSON, XML, CSV, HTML oder Binärdateien übertragen, sofern Client und Server das jeweilige Format vereinbaren.

Was ist ein REST-API-Endpunkt?

Ein Endpunkt ist eine erreichbare Adresse für eine Ressource oder Funktion. Die Kombination aus URL und HTTP-Methode bestimmt die Operation, beispielsweise das Abrufen eines Produkts mit GET oder das Ändern mit PATCH.

Wie wird eine REST-API authentifiziert?

Eine REST-API kann Zugriffstoken, API-Schlüssel oder andere Anmeldeverfahren verwenden. Zugangsdaten sollten verschlüsselt übertragen, zeitlich begrenzt und nur mit den tatsächlich benötigten Berechtigungen ausgestattet werden.

Wie dokumentiert man eine REST-API?

Eine vollständige Dokumentation beschreibt Endpunkte, Methoden, Parameter, Datenformate, Authentifizierung, Statuscodes und Fehlerantworten. Zusätzlich sollten ausführbare Beispielanfragen und die unterstützten API-Versionen angegeben werden.