REST-API
Was ist eine REST-API?
Eine REST-API ist eine Programmierschnittstelle, über die Anwendungen Ressourcen per HTTP abrufen, anlegen, ändern oder löschen. REST steht für Representational State Transfer. Typische REST-APIs verwenden eindeutige URLs, standardisierte HTTP-Methoden, Statuscodes und häufig JSON. Jede Anfrage enthält alle Informationen, die der Server für ihre Verarbeitung benötigt.
REST-API einfach erklärt
Eine REST-API (deutsch: Programmierschnittstelle nach dem REST-Prinzip) verbindet voneinander getrennte Anwendungen über klar definierte Webadressen. Ein Onlineshop kann damit Produktdaten aus einem Warenwirtschaftssystem abrufen, ein Dashboard kann Kennzahlen verschiedener Plattformen zusammenführen und ein CMS kann Inhalte an eine mobile App ausliefern.
REST ist kein festes Übertragungsprotokoll, sondern ein Architekturstil für verteilte Systeme. Eine API gilt deshalb nicht allein durch die Verwendung von HTTP und JSON als REST-konform. Zu den grundlegenden Bedingungen gehören eine Trennung von Client und Server, zustandslose Anfragen, eine einheitliche Schnittstelle, definierte Möglichkeiten zur Zwischenspeicherung und ein mehrschichtiger Systemaufbau.
Wie funktioniert eine REST-API?
Eine REST-API verarbeitet Anfragen nach einem festen Schema. Der Client sendet eine HTTP-Anfrage an einen Endpunkt, ergänzt erforderliche Header und übermittelt bei Bedarf einen Anfragekörper. Der Server prüft die Anfrage, führt die vorgesehene Operation aus und antwortet mit einem HTTP-Statuscode sowie gegebenenfalls mit Daten.
Der Endpunkt /products/42 bezeichnet beispielsweise die Ressource mit der Kennung 42. Welche Aktion ausgeführt wird, ergibt sich aus der HTTP-Methode. Die URL beschreibt damit möglichst das Objekt, während die Methode den Umgang mit diesem Objekt festlegt.
GET /products/42 beginnen. Findet der Server das Produkt, kann er mit dem Statuscode 200 OK und einem JSON-Objekt antworten. Wird keine Ressource mit dieser Kennung gefunden, ist 404 Not Found die passende Antwort. Der Statuscode beschreibt das Ergebnis, während der Antwortkörper die zugehörigen Daten oder eine Fehlermeldung enthält.HTTP-Methoden und ihre Bedeutung
| Methode | Typische Aufgabe | Beispiel |
|---|---|---|
| GET | Ressource lesen | GET /products/42 |
| POST | Neue Ressource anlegen | POST /products |
| PUT | Ressource vollständig ersetzen | PUT /products/42 |
| PATCH | Einzelne Eigenschaften ändern | PATCH /products/42 |
| DELETE | Ressource löschen | DELETE /products/42 |
GET, PUT und DELETE gelten nach der HTTP-Semantik als idempotent. Mehrere identische Anfragen sollen denselben beabsichtigten Zustand erzeugen wie eine einzelne Anfrage. Eine wiederholte DELETE-Anfrage kann zwar beim zweiten Aufruf einen anderen Statuscode liefern, sie löscht die Ressource jedoch nicht mehrfach. POST ist üblicherweise nicht idempotent, weil jeder Aufruf eine neue Ressource erzeugen kann.
Statuscodes richtig auswerten
HTTP-Statuscodes teilen dem Client mit, ob eine REST-Anfrage erfolgreich verarbeitet wurde. Der Code 200 steht für eine erfolgreiche Antwort, 201 für eine neu angelegte Ressource und 204 für eine erfolgreiche Verarbeitung ohne Antwortkörper. Fehler auf Clientseite beginnen mit 4, Serverfehler mit 5.
Eine REST-API sollte Fehler nicht pauschal mit 200 OK beantworten und die eigentliche Fehlermeldung ausschließlich im Antwortkörper verstecken. Monitoring, Caching und automatisierte Clients orientieren sich am HTTP-Status. Eine falsche Statusklasse erschwert deshalb die Fehleranalyse. Die Bedeutung von HTTP 404 und 410 betrifft auch Webseiten und technische SEO-Prüfungen.
Zustandslose REST-Anfragen
Zustandslos bedeutet, dass der Server keine vorherige Anfrage kennen muss, um die nächste Anfrage zu verarbeiten. Jede REST-Anfrage enthält deshalb alle erforderlichen Angaben, etwa die Zielressource, Authentifizierungsinformationen, Parameter und den Inhalt. Der Server darf Daten dauerhaft speichern, aber die Verarbeitung darf nicht von einer versteckten Sitzung auf dem Server abhängen.
Die Zustandslosigkeit erleichtert die Verteilung von Anfragen auf mehrere Server. Ein nachgelagerter Request kann von einer anderen Serverinstanz verarbeitet werden, sofern alle Instanzen auf die erforderlichen Daten zugreifen können. Authentifizierungstoken werden daher häufig mit jeder Anfrage im HTTP-Header übertragen.
Datenformate einer REST-API
JSON ist das verbreitete Datenformat vieler REST-APIs, weil sich strukturierte Inhalte kompakt übertragen und in gängigen Programmiersprachen verarbeiten lassen. REST schreibt JSON jedoch nicht vor. Eine Schnittstelle kann auch XML, CSV, HTML, Bilder oder andere Repräsentationen einer Ressource ausliefern.
Der Client teilt über den Header Accept mit, welches Antwortformat er verarbeiten kann. Der Header Content-Type beschreibt das Format der übertragenen Daten. Bei einem JSON-Anfragekörper lautet die Angabe üblicherweise application/json. Stimmen Format und Header nicht überein, kann der Server die Anfrage mit einem Fehler ablehnen.
Sicherheit bei REST-APIs
Eine öffentlich erreichbare REST-API benötigt eine verschlüsselte HTTPS-Verbindung, eine nachvollziehbare Authentifizierung und eine getrennte Berechtigungsprüfung. Ein API-Schlüssel identifiziert häufig die aufrufende Anwendung. OAuth 2.0 ermöglicht delegierte Zugriffe, während JSON Web Tokens ein Format für signierte Informationen darstellen und nicht automatisch ein vollständiges Berechtigungskonzept ersetzen.
REST-API im Online-Marketing
REST-APIs verbinden im Online-Marketing Datenquellen mit CMS, Shopsystemen, Dashboards und internen Analyseprozessen. SEO-Daten können automatisiert in Berichte einfließen, SEA-Systeme können Kampagnendaten austauschen und GEO, also Generative Engine Optimization, kann Informationen aus verschiedenen KI-Monitorings zusammenführen. Die REST-API selbst verbessert jedoch kein Ranking. Ihr Nutzen entsteht durch verlässliche Daten und Prozesse, die auf der Schnittstelle aufbauen.
Bei umfangreichen Websites können REST-APIs außerdem Inhalte, Metadaten oder Produktinformationen an mehrere Ausgabekanäle liefern. Eine technische Prüfung muss dabei berücksichtigen, ob relevante Inhalte bereits im HTML stehen oder erst nachträglich durch JavaScript geladen werden. Suchmaschinen können dynamische Inhalte verarbeiten, doch fehlerhafte Requests, lange Antwortzeiten und unzugängliche Endpunkte erschweren das Crawling. Solche Abhängigkeiten gehören in eine strukturierte technische SEO-Prüfung.
Messbar ist eine REST-API unter anderem über Antwortzeit, Fehlerrate, Verfügbarkeit und Anzahl der Anfragen. Ein technisches Monitoring sollte erfolgreiche Requests und Statuscodes getrennt auswerten. Eine steigende Quote von 4xx-Codes weist meist auf fehlerhafte Aufrufe hin, während 5xx-Codes eine serverseitige Störung anzeigen. Bei einer neuen Website mit SEO-Fokus sollten diese Messpunkte bereits in der technischen Konzeption festgelegt werden.
REST-API, SOAP und GraphQL
| Ansatz | Grundprinzip | Typische Eigenschaft |
|---|---|---|
| REST | Ressourcen werden über einheitliche HTTP-Methoden angesprochen. | Einfach mit Webstandards kombinierbar. |
| SOAP | Nachrichten folgen einem standardisierten XML-Protokoll. | Umfangreiche Standards für Verträge und Nachrichtensicherheit. |
| GraphQL | Der Client beschreibt die benötigten Felder in einer Abfrage. | Flexible Datenabfrage über einen zentralen Endpunkt. |
| Webhook | Ein System sendet bei einem Ereignis automatisch eine Nachricht. | Ereignisgesteuerte Übertragung ohne regelmäßige Abfrage. |
Der Unterschied zwischen REST und SOAP liegt bereits in der technischen Einordnung: REST ist ein Architekturstil, SOAP ein Nachrichtenprotokoll. SOAP definiert strengere Standards und verwendet typischerweise XML. REST lässt mehr Freiraum bei Datenformaten und Implementierung, verlangt für eine saubere Architektur aber die Einhaltung seiner grundlegenden Bedingungen.
Der Unterschied zwischen REST und GraphQL liegt vor allem in der Datenabfrage. REST verteilt Ressourcen häufig auf mehrere Endpunkte mit vorgegebenen Antwortstrukturen. GraphQL erlaubt dem Client, benötigte Felder gezielt anzufordern. GraphQL verhindert dadurch überflüssige Datenübertragung in bestimmten Anwendungsfällen, erhöht aber die Anforderungen an Caching, Berechtigungen und die Begrenzung komplexer Abfragen.
REST-API sauber planen
Eine belastbare REST-API beginnt mit einem fachlichen Ressourcenmodell. Endpunkte sollten Substantive wie /orders oder /customers verwenden. Aktionen wie /getCustomer wiederholen die Bedeutung der HTTP-Methode und führen mit wachsendem Funktionsumfang häufig zu uneinheitlichen Schnittstellen.
Eine kurze Praxis-Beobachtung aus Webprojekten: Integrationen scheitern selten am ersten erfolgreichen Request. Probleme entstehen meist bei abgelaufenen Token, leeren Ergebnissen, Anfragelimits und Änderungen an Datenfeldern. Testfälle sollten deshalb neben dem Erfolgsfall mindestens ungültige Eingaben, fehlende Berechtigungen, Zeitüberschreitungen und nicht erreichbare Dienste abdecken.
Häufige Fragen zur REST-API
Ist eine REST-API immer in JSON aufgebaut?
Nein. JSON wird häufig verwendet, ist aber keine Bedingung von REST. Eine REST-API kann unter anderem XML, CSV, HTML oder Binärdaten übertragen, sofern Client und Server das Format eindeutig vereinbaren.
Was ist ein Endpunkt bei einer REST-API?
Ein Endpunkt ist eine Adresse, unter der eine Ressource oder Funktion erreichbar ist. Die Kombination aus URL und HTTP-Methode bestimmt, ob Daten gelesen, angelegt, geändert oder gelöscht werden.
Was bedeutet RESTful?
RESTful bezeichnet eine API, die sich an den Bedingungen des REST-Architekturstils orientiert. Eine Schnittstelle mit HTTP und JSON ist daher nicht automatisch RESTful, wenn sie beispielsweise serverseitige Sitzungszustände voraussetzt oder keine einheitliche Schnittstelle bietet.
Kann eine REST-API direkt im Browser aufgerufen werden?
GET-Endpunkte lassen sich grundsätzlich im Browser öffnen, sofern sie öffentlich erreichbar sind und keine besonderen Header benötigen. Für geschützte oder verändernde Anfragen brauchst du meist ein Entwicklungswerkzeug, ein Skript oder eine Anwendung.
Wie lässt sich eine REST-API testen?
Eine REST-API lässt sich mit einem API-Client, automatisierten Tests oder Kommandozeilenwerkzeugen prüfen. Teste neben erfolgreichen Anfragen auch ungültige Daten, fehlende Rechte, nicht vorhandene Ressourcen, Anfragelimits und Zeitüberschreitungen.
Braucht eine REST-API immer HTTP?
Die REST-Architektur ist theoretisch nicht auf HTTP beschränkt. In der Webentwicklung werden REST-APIs jedoch fast immer mit HTTP umgesetzt, weil Methoden, Header, Statuscodes und Caching bereits passende Standards bereitstellen.
Ist eine REST-API automatisch sicher?
Nein. Die Sicherheit hängt von HTTPS, Authentifizierung, Berechtigungsprüfungen, Eingabevalidierung, Protokollierung und Anfragelimits ab. Jede geschützte Operation muss serverseitig prüfen, ob der aufrufende Client genau diese Ressource bearbeiten darf.
Du planst eine Website oder technische Schnittstelle, bei der SEO, Datenzugriff und Systemarchitektur gemeinsam berücksichtigt werden sollen? Ein unverbindliches Erstgespräch schafft Klarheit über Anforderungen und mögliche Abhängigkeiten.
Sie haben noch Fragen?
