Eine REST-API (Representational State Transfer) ist eine Schnittstelle, ueber die zwei Systeme strukturiert Daten austauschen — und zwar nach einem festen Satz von Architekturregeln, die der Informatiker Roy Fielding im Jahr 2000 in seiner Dissertation beschrieben hat. Wenn dein Onlineshop Bestelldaten an ein ERP schickt, deine Mobile App den Warenkorb laedt oder ein Zahlungsdienstleister eine Transaktion bestaetigt, dann passiert das in den allermeisten Faellen ueber eine REST-API. REST ist heute der De-facto-Standard fuer Web-Schnittstellen — nicht weil es die einzige Option ist, sondern weil es robust, verstaendlich und ueber System- und Sprachgrenzen hinweg interoperabel ist. Fuer dich als Entscheider im Mittelstand bedeutet das vor allem eines: Eine sauber gebaute REST-API ist die Grundlage dafuer, dass deine Systeme miteinander reden, dass du Partner anbinden kannst und dass deine Software auch in fuenf Jahren noch wartbar bleibt.
Was REST im Kern ausmacht
REST ist kein Protokoll und keine Technologie, sondern ein Architekturstil. Das ist ein wichtiger Unterschied: Es schreibt dir nicht vor, welche Programmiersprache oder welches Framework du nutzt, sondern definiert Prinzipien, an die sich eine Schnittstelle halten sollte, um "RESTful" zu sein. Die zentrale Idee ist die Ressourcenorientierung: Alles, was deine API verwaltet — ein Kunde, eine Bestellung, ein Produkt — ist eine Ressource mit einer eindeutigen Adresse (URI). Du sprichst diese Ressourcen ueber URLs an, etwa /kunden/4711 oder /bestellungen/2026-001.
Auf diese Ressourcen wendest du die Standard-HTTP-Methoden an, statt eigene Verben zu erfinden. Genau das macht REST so vorhersehbar: Jeder Entwickler, der HTTP kennt, versteht sofort, was eine Anfrage tun soll. Ein gutes REST-Design liest sich fast wie ein Satz — "hole die Bestellung mit der ID 2026-001" wird zu GET /bestellungen/2026-001. Diese Selbsterklaerbarkeit senkt die Einarbeitungszeit neuer Teammitglieder, reduziert Dokumentationsaufwand und macht die Schnittstelle fuer externe Partner leichter konsumierbar. Wichtig ist dabei die Trennung zwischen Substantiven (den Ressourcen, die in der URL stehen) und Verben (den HTTP-Methoden, die die Aktion bestimmen). Eine URL wie /erstelleBestellung ist ein klassischer Anti-Pattern — die Aktion gehoert in die Methode, nicht in den Pfad.
Die wichtigsten HTTP-Methoden
- GET — Ressource lesen, ohne sie zu veraendern (sicher und idempotent). Mehrfaches Aufrufen aendert nie etwas am Serverzustand.
- POST — eine neue Ressource anlegen (nicht idempotent: zweimal gesendet, zwei Datensaetze — ein haeufiger Grund fuer versehentliche Doppelbestellungen).
- PUT — eine Ressource vollstaendig ersetzen oder anlegen (idempotent: dasselbe PUT zweimal fuehrt zum selben Ergebnis).
- PATCH — eine Ressource teilweise aktualisieren, etwa nur das Lieferdatum einer Bestellung.
- DELETE — eine Ressource loeschen (idempotent: was weg ist, bleibt weg).
Der Unterschied zwischen idempotenten und nicht-idempotenten Methoden ist in der Praxis entscheidend fuer die Fehlertoleranz deiner Systeme. Faellt eine Netzwerkverbindung kurz aus und der Client wiederholt eine Anfrage, darf das bei einem GET oder PUT keinen Schaden anrichten — bei einem POST sehr wohl. Mehr dazu im Glossareintrag zu Idempotenz.
Die sechs Architekturprinzipien
Damit eine API wirklich RESTful ist, muss sie eine Reihe von Constraints erfuellen. Roy Fielding hat sechs definiert, und jeder einzelne hat eine konkrete Auswirkung auf Skalierbarkeit, Wartbarkeit und Betriebssicherheit:
- Client-Server-Trennung — Frontend und Backend sind entkoppelt und entwickeln sich unabhaengig weiter. Dein Web-Frontend, deine iOS-App und das Partner-Portal koennen alle dieselbe API nutzen, ohne dass das Backend wissen muss, wer fragt.
- Zustandslosigkeit (Stateless) — jede Anfrage enthaelt alle Informationen, die der Server zur Bearbeitung braucht. Der Server speichert keinen Sitzungszustand zwischen zwei Requests. Das ist der Schluessel zur horizontalen Skalierbarkeit: Du kannst beliebig viele Server-Instanzen hinter einen Load Balancer haengen, weil keine Instanz "weiss", was vorher passiert ist. Genau das brauchst du, wenn dein Shop am Black Friday das Zehnfache an Last verarbeiten muss.
- Cachebarkeit — Antworten kennzeichnen ueber Header wie
Cache-ControlundETag, ob und wie lange sie zwischengespeichert werden duerfen. Gutes Caching entlastet die Datenbank massiv und macht haeufig abgefragte Daten (Produktkataloge, Kategorien) blitzschnell. - Einheitliche Schnittstelle (Uniform Interface) — der wichtigste und namensgebende Constraint: Ressourcen werden konsistent ueber URIs adressiert und ueber standardisierte Methoden manipuliert.
- Mehrschichtigkeit (Layered System) — zwischen Client und Server duerfen Proxies, Gateways oder Caches liegen, ohne dass der Client das merkt. Genau hier setzt ein API-Gateway an.
- Code on Demand (optional) — der Server darf ausfuehrbaren Code an den Client schicken, etwa JavaScript. Dies ist der einzige optionale Constraint.
In der Realitaet erfuellen viele "REST-APIs" nicht alle sechs Constraints strikt — der Branchenstandard ist eher ein pragmatisches "RESTful genug". Das ist okay, solange die Trade-offs bewusst getroffen werden. Wer etwa auf strikte Cachebarkeit verzichtet, sollte das aus einem guten Grund tun und nicht aus Unwissenheit.
HTTP-Status-Codes richtig nutzen
Eine gute REST-API kommuniziert das Ergebnis ueber den HTTP-Status-Code, nicht ueber ein selbstgebautes Feld im Response-Body. Das ist mehr als Kosmetik: Monitoring-Tools, Load Balancer, Caches und Client-Bibliotheken werten den Status-Code automatisch aus. Wer das ignoriert, verschenkt einen Grossteil der Infrastruktur, die das Web ohnehin mitbringt. Die wichtigsten Gruppen:
| Bereich | Bedeutung | Typische Beispiele |
|---|---|---|
| 2xx | Erfolg | 200 OK, 201 Created, 204 No Content |
| 3xx | Umleitung / Caching | 301 Moved Permanently, 304 Not Modified |
| 4xx | Client-Fehler | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests |
| 5xx | Server-Fehler | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable |
Wer einen fehlgeschlagenen Login mit 200 OK und {"error": true} beantwortet, bricht mit dem Uniform-Interface-Prinzip und macht es Clients, Monitoring-Tools und Caches unnoetig schwer. Genauso wichtig: ein 429 Too Many Requests signalisiert Rate-Limiting sauber, sodass ein gut gebauter Client mit Backoff reagieren kann, statt den Server weiter zu fluten.
REST in der Praxis: bekannte Beispiele
Die Stripe-API fuer Zahlungsabwicklung gilt als Paradebeispiel fuer sauberes REST-Design: klare Ressourcen (/v1/charges, /v1/customers), konsistente Status-Codes, durchdachtes Pagination-Modell und exzellente Dokumentation. Auch die GitHub REST API und die Shopify Admin API sind weit verbreitete, gut dokumentierte REST-Schnittstellen, an denen man sich beim eigenen Design orientieren kann. Im E-Commerce-Umfeld bietet auch Shopware eine umfangreiche Admin- und Store-API nach REST-Prinzipien an, ueber die sich der Shop mit ERP-, PIM- und Marketing-Systemen verbinden laesst — die Basis fuer jede ernsthafte Integration im Onlinehandel.
Zur formalen Beschreibung einer REST-API hat sich die OpenAPI-Spezifikation (frueher Swagger) durchgesetzt. Sie beschreibt Endpunkte, Parameter und Datenmodelle maschinenlesbar in einer YAML- oder JSON-Datei — daraus lassen sich Dokumentation, Client-SDKs in diversen Sprachen und Test-Stubs automatisch generieren. Fuer dich heisst das konkret: Du kannst deine Schnittstelle einmal sauber spezifizieren und sparst danach an vielen Stellen manuelle Arbeit. In unseren Enterprise-Projekten ist die OpenAPI-Spezifikation deshalb haeufig der zentrale Vertrag zwischen Backend- und Frontend-Team.
Versionierung und Abwaertskompatibilitaet
Eine produktive API lebt jahrelang und wird von Systemen genutzt, die du nicht alle gleichzeitig aktualisieren kannst. Deshalb gehoert ein Versionierungskonzept von Anfang an dazu — ueblich ist die Version im Pfad (/v1/, /v2/) oder im Header. Die goldene Regel: Bestehende Felder nie stillschweigend umdeuten oder entfernen. Neue Felder hinzufuegen ist fast immer abwaertskompatibel, das Entfernen oder Umbenennen ist es nie. Wer das missachtet, legt unangekuendigt Partner-Integrationen lahm — einer der teuersten Fehler im API-Betrieb.
Wann REST passt — und wann nicht
REST ist die richtige Wahl, wenn deine Schnittstelle klar ressourcenorientiert ist, du breite Interoperabilitaet und gutes Caching brauchst und viele unterschiedliche Clients (Web, Mobile, Drittsysteme) bedienen willst. An Grenzen stoesst REST, wenn Clients sehr unterschiedliche, tief verschachtelte Datenmengen brauchen — dann fuehren das klassische Over-Fetching (zu viele Daten pro Antwort) und Under-Fetching (mehrere Roundtrips fuer eine Ansicht noetig) zu Ineffizienz, besonders auf mobilen Verbindungen. Fuer solche Faelle ist GraphQL oft die bessere Alternative. In Microservices-Landschaften wird REST haeufig fuer synchrone Service-zu-Service-Kommunikation eingesetzt, ergaenzt durch ereignisgetriebene Muster wie Webhooks fuer asynchrone Benachrichtigungen. In der Praxis ist die Frage selten "REST oder etwas anderes", sondern "welcher Stil fuer welchen Anwendungsfall" — und in den meisten Backends ist REST der solide Standardfall.
Mehr zu den Architekturregeln von REST findest du in der offiziellen Beschreibung bei MDN Web Docs.
Authentifizierung und Absicherung
Sobald deine REST-API mehr tut als oeffentliche Daten auszuliefern, brauchst du ein Authentifizierungs- und Autorisierungskonzept. Verbreitet sind API-Keys fuer Server-zu-Server-Kommunikation, OAuth 2.0 mit Bearer-Tokens fuer Drittanbieter-Zugriffe und JSON Web Tokens (JWT), die der zustandslosen Natur von REST entgegenkommen, weil sie alle noetigen Claims selbst transportieren. Eine produktive API gehoert ausschliesslich hinter TLS (HTTPS), ergaenzt um Rate-Limiting, Eingabevalidierung und ein durchdachtes Berechtigungsmodell. Gerade im B2B-Umfeld, wo eine Schnittstelle oft sensible Bestell-, Preis- oder Kundendaten transportiert, ist Sicherheit kein nachgelagertes Thema, sondern Teil des Designs von Tag eins an. Wer das verschiebt, baut sich ein teures Nachruest-Projekt.
Haeufige Fragen zu REST-APIs
Was bedeutet REST ausgeschrieben?
REST steht fuer Representational State Transfer und beschreibt einen Architekturstil fuer verteilte Systeme, der von Roy Fielding im Jahr 2000 definiert wurde.
Ist REST dasselbe wie HTTP?
Nein. HTTP ist das Transportprotokoll, das REST in der Praxis fast immer nutzt. REST selbst ist ein Architekturstil, der theoretisch auch mit anderen Protokollen funktionieren koennte, in der Realitaet aber praktisch immer auf HTTP aufsetzt.
Was ist der Unterschied zwischen REST und SOAP?
SOAP ist ein striktes, XML-basiertes Protokoll mit festem Nachrichtenformat und eigenem Standard-Stack. REST ist leichtgewichtiger, nutzt meist JSON und setzt auf die nativen HTTP-Mechanismen. REST ist heute im Web deutlich verbreiteter, SOAP findet sich noch in aelteren Enterprise- und Behoerden-Schnittstellen.
Was heisst zustandslos bei REST?
Der Server speichert zwischen zwei Anfragen keinen Sitzungszustand. Jede Anfrage muss alle noetigen Informationen mitbringen, etwa ein Auth-Token. Das ermoeglicht horizontale Skalierung ueber viele Server-Instanzen.
Brauche ich fuer eine REST-API zwingend JSON?
Nein, aber JSON ist das de facto uebliche Format. REST ist formatunabhaengig — ueber den Accept-Header kann ein Client auch XML oder andere Repraesentationen anfordern (Content Negotiation).