Representational State Transfer (REST) beschreibt ein Architekturstil für verteilte Systeme, der vor allem bei Web-APIs Anwendung findet. Anstatt einen starren Protokollsatz vorzugeben, definiert REST Prinzipien und Einschränkungen, die zu einer skalierbaren, wartbaren und lose gekoppelten Architektur führen. In der Praxis bedeutet dies: Ressourcen werden über eindeutige URLs adressiert, über standardisierte HTTP-Methoden manipuliert und in verschiedenen Repräsentationen (z. B. JSON) übertragen.
Zentrale REST-Prinzipien
- Ressourcenorientierung: Fachliche Entitäten wie /kunden oder /bestellungen werden als Ressourcen modelliert und eindeutig per URI angesprochen.
- Repräsentationen: Eine Ressource kann in unterschiedlichen Formaten dargestellt werden (JSON, XML, CSV). Der Inhaltstyp wird über HTTP-Header (z. B.
Content-Type,Accept) ausgehandelt. - Statelessness: Jeder Request enthält alle notwendigen Informationen. Der Server hält keinen Sitzungskontext, wodurch horizontale Skalierung vereinfacht wird.
- Einheitliche Schnittstelle: Einheitliche Regeln für Adressierung, Methoden und Statuscodes fördern Interoperabilität und Vorhersagbarkeit.
- Cachebarkeit: Antworten können explizit als cachebar markiert werden, um Latenzen und Serverlast zu reduzieren.
- Schichtarchitektur: Proxies, Gateways und Load Balancer lassen sich einfügen, ohne die Semantik der Schnittstelle zu verändern.
HTTP-Methoden und Semantik
REST nutzt die vorhandene Semantik des HTTP-Protokolls:
GETliest Ressourcen (sicher, idempotent).POSTerstellt Unterressourcen oder triggert serverseitige Vorgänge (nicht idempotent).PUTersetzt eine Ressource vollständig (idempotent).PATCHnimmt partielle Änderungen vor (nicht zwingend idempotent, aber häufig so implementiert).DELETEentfernt Ressourcen (idempotent).
Ergänzend transportieren Statuscodes wie 200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 404 Not Found oder 409 Conflict klare Ergebniszustände. Präzise Fehlerobjekte mit Maschinencodes und Trace-IDs erleichtern Diagnose und Automatisierung.
Ressourcendesign und Versionierung
Ein sauberes Ressourcendesign folgt konsistenten, sprechenden Pfaden und nutzt Subressourcen für Beziehungen, etwa /kunden/{id}/bestellungen. Filterung, Sortierung und Pagination werden meist per Query-Parametern umgesetzt (?page=2&limit=50, ?sort=-datum). Versionierung geschieht entweder über den Pfad (/v1/…) oder über Medien-Typen (Content Negotiation). Stabilität der Verträge hat hohe Priorität; Breaking Changes erfordern neue Versionen.
Sicherheit und Governance
Transportverschlüsselung via TLS ist obligatorisch. Für Authentifizierung und Autorisierung kommen häufig OAuth 2.0 bzw. OpenID Connect mit Bearer-Tokens zum Einsatz. Rate-Limiting, Quotas und API-Keys dienen der Missbrauchsprävention. Zur Nachvollziehbarkeit werden Audit-Logs, Korrelation von Requests (z. B. Correlation-ID) und strukturierte Telemetrie etabliert. Input-Validierung und Output-Encoding schützen vor gängigen Schwachstellen wie Injection oder Mass Assignment.
Dokumentation und Testbarkeit
Maschinenlesbare Spezifikationen wie OpenAPI erleichtern Generierung von Client-SDKs, Mock-Servern und Tests. Beispielanfragen, Feldbeschreibungen sowie Fehlerkataloge erhöhen die Entwicklerfreundlichkeit. Contract-Tests stellen sicher, dass Implementierung und Spezifikation synchron bleiben.
Leistung und Skalierung
Caching auf Client-, Proxy- und Serverebene reduziert Latenzen. Komprimierung (Gzip/Brotli), selektive Feldauswahl (sparse fieldsets) und Paginierung minimieren Payload-Größen. Idempotenz, asynchrone Verarbeitungsmuster und Event-Benachrichtigungen (Webhooks) unterstützen robuste, skalierbare Abläufe. Für große Datenmengen bieten asynchrone Export-Jobs mit Polling oder Callback-Mechanismen bessere Nutzererfahrung als lange laufende Requests.
Abgrenzung und Grenzen
REST konkurriert nicht zwingend mit Alternativen, sondern ergänzt sie. SOAP liefert strenge Verträge und erweiterte Protokollfunktionen, ist jedoch schwergewichtiger. GraphQL bietet flexible Abfragen und reduziert Over-/Underfetching, erfordert aber eigene Serverlogik und Observability-Strategien. Bei REST können zu grobe oder zu feingranulare Ressourcen, uneinheitliche Fehlerformate und fehlende Konsistenz die Vorteile schmälern.
REST-APIs verbinden das HTTP-Ökosystem mit klaren Architekturprinzipien zu einer pragmatischen, weit verbreiteten Lösungsform. Konsequente Nutzung der HTTP-Semantik, sauber modellierte Ressourcen, verlässliche Versionierung sowie strenge Sicherheits- und Qualitätspraktiken bilden die Grundlage für langlebige und skalierbare Schnittstellen.