REST API

Was bedeutet REST?

REST steht für Representational State Transfer. Roy Fielding beschrieb REST im Jahr 2000 in seiner Dissertation über Architekturstile netzwerkbasierter Softwarearchitekturen. REST ist damit kein einzelnes Protokoll und keine Programmiersprache, sondern ein Architekturstil mit mehreren Constraints.

Im Alltag wird „REST API“ oft als Synonym für eine HTTP-API verwendet, die JSON zurückgibt. Das ist fachlich zu kurz gegriffen. Eine Schnittstelle kann HTTP und JSON verwenden, ohne die REST-Constraints konsequent umzusetzen.

Fachliche Grundlage: Fieldings REST-Constraints

Zu den zentralen REST-Constraints gehören:

• Client-Server: Benutzeroberfläche und Daten-/Serverlogik werden getrennt.
• Stateless: Jede Anfrage enthält die Informationen, die für ihre Verarbeitung erforderlich sind; Sitzungszustand soll nicht versteckt zwischen Anfragen auf dem Server vorausgesetzt werden.
• Cache: Antworten müssen klar machen können, ob und wie sie zwischengespeichert werden dürfen.
• Uniform Interface: Eine einheitliche Schnittstelle reduziert Kopplung und ist ein zentrales REST-Merkmal.
• Layered System: Clients müssen nicht wissen, ob sie direkt mit dem Ursprungssystem oder mit einer Zwischenkomponente kommunizieren.
• Code on Demand: optional kann ausführbarer Code übertragen werden.

Ressourcen und Repräsentationen

REST denkt stark in Ressourcen. Eine Ressource kann beispielsweise ein Kunde, Auftrag oder Dokument sein. Über eine URI wird sie identifiziert. Ein Server überträgt nicht „die Ressource selbst“, sondern eine Repräsentation – etwa JSON.

Welche Rolle spielen HTTP-Methoden?

HTTP definiert Methoden mit eigener Semantik. Typische API-Operationen verwenden:

• GET zum Abrufen,
• POST für anwendungsabhängige Verarbeitung beziehungsweise häufig zum Erzeugen,
• PUT zum Ersetzen oder Anlegen einer Ressource unter einer bekannten URI,
• PATCH für partielle Änderungen,
• DELETE zum Löschen.

Die genaue HTTP-Semantik sollte nicht allein aus Framework-Konventionen abgeleitet werden. RFC 9110 ist die normative Grundlage für HTTP-Semantik.

Stateless bedeutet nicht „ohne Datenbank“

Ein verbreiteter Irrtum: REST-Statelessness bedeute, dass der Server keinen Zustand speichern dürfe. Gemeint ist der für die Verarbeitung der Client-Anfrage relevante Sessionzustand zwischen Requests. Eine REST-Anwendung kann selbstverständlich Datenbanken, Aufträge oder Benutzerkonten speichern.

Wann ist eine REST-orientierte API sinnvoll?

REST passt gut zu vielen CRUD- und Ressourcen-orientierten Integrationen, insbesondere wenn HTTP-Infrastruktur, Caches und Standardmechanismen genutzt werden sollen. Nicht jeder Anwendungsfall muss jedoch als REST modelliert werden. Für komplexe Abfragen, Streaming, Eventing oder stark RPC-orientierte Operationen können andere Ansätze geeigneter sein.

Typische Qualitätsprobleme

• HTTP-Statuscodes werden inkonsistent verwendet.
• Jede Aktion wird als POST modelliert.
• Versionierung und Abwärtskompatibilität fehlen.
• Fehlerantworten haben kein stabiles Schema.
• Authentifizierung wird mit Autorisierung verwechselt.
• „RESTful“ wird behauptet, ohne die zugrunde liegenden Constraints zu verstehen.

REST API und OpenAPI

OpenAPI kann HTTP-Schnittstellen maschinenlesbar dokumentieren. Es ist jedoch keine REST-Spezifikation. Eine OpenAPI-Datei kann eine sehr REST-nahe oder eine eher RPC-artige HTTP-API beschreiben.

REST-Konformität ist kein Selbstzweck

Bei internen Integrationen ist ein pragmatischer HTTP-Vertrag manchmal sinnvoller als eine dogmatische Diskussion über „100 Prozent REST“. Trotzdem ist die Kenntnis der Constraints wertvoll, weil sie erklärt, warum Eigenschaften wie Statelessness, Cachebarkeit und Uniform Interface Skalierbarkeit und Entkopplung fördern können.

Die Architekturentscheidung sollte dokumentieren, welche REST-Eigenschaften bewusst genutzt oder nicht genutzt werden. So lässt sich später unterscheiden, ob eine Abweichung fachlich begründet ist oder nur historisch entstanden ist.

Fazit

REST APIs sind dann fachlich sauber beschrieben, wenn REST als Architekturstil verstanden wird. Für Unternehmen ist weniger wichtig, ob jede akademische REST-Eigenschaft maximal umgesetzt ist, sondern ob die gewählten Constraints bewusst zur Integration passen, Schnittstellen stabil dokumentiert sind und Änderungen kontrolliert erfolgen.