REST, GraphQL oder RPC — die Wahl des API-Stils

Über kaum eine API-Entscheidung wird so viel nach Zeitgeist geurteilt wie über den Stil. Mal gilt das eine als modern und das andere als überholt, mal kehrt sich die Mode wieder um — und in beiden Fällen wird eine Passungsfrage als Geschmacksfrage geführt. Dabei benennen REST, GraphQL und RPC keine Qualität, sondern drei verschiedene Arten, wie zwei Systeme miteinander sprechen. Die brauchbare Frage ist nicht, welcher Stil besser ist, sondern welche Form ein Problem hat und welcher Stil zu dieser Form passt.

Dieses Dokument behandelt die drei Stile als das, was sie sind: Werkzeuge mit unterschiedlicher Form, jedes stark für bestimmte Probleme und schwach für andere. Es ist protokoll- und produktneutral gehalten und setzt die Prinzipien des langlebigen API-Entwurfs voraus, die an anderer Stelle behandelt sind — Verträge, Kompatibilität, Vertrauensgrenzen. Hier geht es allein um die vorgelagerte Entscheidung, in welchem Stil man diesen Vertrag überhaupt formt. Genannt werden keine Zahlen.

1. Die falsche Frage

„Welcher API-Stil ist der beste?" ist die falsche Frage, weil sie eine allgemeine Antwort erwartet, wo es nur situationsabhängige gibt. Jeder der drei Stile ist für manche Probleme die passende Wahl und für andere ein Umweg. Wer nach dem besten Stil sucht, führt einen Modestreit; wer nach dem passenden sucht, stellt die nützliche Frage: Wie sieht die Kommunikation aus, die hier stattfinden soll — wer ruft wen wie oft und wozu?

Der Grund, warum die Stilwahl überhaupt zählt, liegt in ihrer Langlebigkeit. Der Stil prägt die Form des Vertrags zwischen den Systemen, und dieser Vertrag ist, wie jede Schnittstelle, schwer zu ändern, sobald andere sich darauf verlassen. Man wählt den Stil deshalb am besten bewusst und aus einem Grund, nicht aus Gewohnheit oder Mode — denn man wird lange mit ihm leben. Die Frage vor der Stilwahl ist immer die Frage nach dem Problem.

Erschwerend kommt hinzu, dass ein einmal gewählter Stil schwer zu wechseln ist. Weil er den Vertrag prägt, auf den sich fremde Systeme verlassen, zieht ein Stilwechsel dieselbe Last nach sich wie jede tiefe Änderung an einer Schnittstelle — man kann ihn nicht einseitig vollziehen, ohne die Aufrufer zu berühren. Das erhöht den Einsatz der ursprünglichen Wahl: Sie ist keine, die man beiläufig trifft und später leicht korrigiert, sondern eine, die man lange trägt. Umso mehr lohnt es, sie bewusst und aus einem benennbaren Grund zu treffen.

Trade-off. Die Frage nach der Passung statt nach dem besten Stil zu stellen bedeutet, auf die Bequemlichkeit einer allgemeinen Empfehlung zu verzichten und für das eigene System zu urteilen.

Kosten. Das Urteil verlangt, die eigene Kommunikationsform genau zu verstehen, bevor man den Stil wählt — mehr Arbeit als der Griff zum Vertrauten.

Wann wir anders entscheiden. Wo ein Team einen Stil tief beherrscht und das Problem in dessen Form passt, ist die lange Abwägung überflüssig; die Vertrautheit gibt dann berechtigt den Ausschlag.

2. Was die drei Stile wirklich unterscheiden

Die drei Stile unterscheiden sich darin, worum sich die Kommunikation dreht. REST dreht sich um Ressourcen: benannte Dinge, die man abruft und verändert, über eine kleine, feste Menge von Operationen. Sein Vorbild ist die Struktur des Webs selbst, und seine Stärke ist Einfachheit und Verbreitung — fast jeder kennt es, fast alles unterstützt es. RPC dreht sich um Aktionen: man ruft eine benannte Funktion in einem fremden System auf, als wäre sie eine eigene. Seine Stärke ist Direktheit — wo es um das Ausführen von Operationen geht, ist der Aufruf einer Funktion die naheliegendste Form.

GraphQL dreht sich um Abfragen: der Aufrufer beschreibt genau, welche Daten er will, und bekommt genau diese zurück, in einer Anfrage, auch über viele verbundene Dinge hinweg. Seine Stärke ist Flexibilität auf der Seite des Aufrufers — er holt in einem Zug, was er sonst über viele Aufrufe zusammensuchen müsste. Diese drei Formen sind nicht besser oder schlechter, sondern verschieden: Ressourcen abrufen, Aktionen ausführen, Daten flexibel abfragen. Die Frage ist, welche dieser Formen die eigene Kommunikation hat.

In der Praxis sind die Grenzen zwischen den Stilen weniger scharf, als die Namen vermuten lassen. Man kann eine ressourcenorientierte Schnittstelle um einige aktionsartige Aufrufe ergänzen, ohne den Stil zu verraten; man kann eine flexible Abfrage über eine ansonsten schlichte Schnittstelle legen, wo sie wirklich gebraucht wird. Die drei Stile sind Neigungen, keine Gefängnisse — und der Fehler ist nicht, sie zu mischen, sondern sie zu verwechseln: eine Kommunikation in einer Form auszudrücken, die ihr nicht entspricht, nur weil man sich auf einen Stil festgelegt hat.

Trade-off. Die Form ernst zu nehmen bedeutet, den Stil nach der Art der Kommunikation zu wählen, statt einen Stil auf jede Kommunikation zu zwingen.

Kosten. Die genaue Betrachtung kostet Zeit und die ehrliche Analyse dessen, was zwischen den Systemen wirklich fließt.

Wann wir anders entscheiden. Wo ein System mehrere Kommunikationsformen enthält, kann es richtig sein, für verschiedene Teile verschiedene Stile zu wählen, statt das Ganze in einen zu pressen.

3. Wann REST genügt — und das ist oft

Der häufigste Fall ist zugleich der unscheinbarste: Für die meisten Systeme genügt REST, und Einfachheit ist ein Wert, den man nicht leichtfertig aufgibt. Wo die Kommunikation im Kern darin besteht, benannte Dinge abzurufen und zu verändern — und das trifft auf einen Großteil betrieblicher Software zu —, ist REST die naheliegende, verbreitete und ruhige Wahl. Es ist überall verstanden, überall unterstützt, gut zwischenspeicherbar und leicht zu betreiben. Seine Schlichtheit ist kein Mangel, sondern der Grund, warum es über Jahre trägt.

Schema: Kein Stil ist der Ausgangspunkt. Man fragt nach der Form der Kommunikation — Dinge, Aktionen oder flexible Abfragen — und wählt danach. Für die breite Mitte ist die Form „Dinge", und dort gewinnt REST.

Ein konkreter, oft unterschätzter Vorteil von REST ist die Zwischenspeicherung. Weil der Abruf eines benannten Dings eine klare, wiederholbare Anfrage ist, lässt sich seine Antwort auf dem Weg zwischen Anbieter und Aufrufer zwischenspeichern — an vielen Stellen, mit den bewährten Mitteln des Webs. Das entlastet die Quelle und beschleunigt den Aufrufer, ohne dass das System etwas Besonderes dafür tun müsste. Reichere Stile, deren Anfragen weniger vorhersehbar sind, geben diesen Vorteil zu einem guten Teil auf — ein stiller Preis, der sich erst unter Last zeigt und den man beim Vergleich der Stile leicht übersieht.

Der Reiz, statt des schlichten REST einen reicheren Stil zu wählen, ist groß, weil er moderner wirkt — aber wo REST das Problem löst, ist ein reicherer Stil kein Fortschritt, sondern eine Verkomplizierung. Man tauscht eine Lösung, die jeder versteht und die sich mühelos betreiben lässt, gegen eine, die mehr kann, als man braucht, und dafür mehr Aufwand, mehr Betrieb und mehr Wissen verlangt. Einfachheit dort aufzugeben, wo sie genügt, ist selten eine gute Wette.

Trade-off. REST zu wählen kauft Einfachheit, Verbreitung und ruhigen Betrieb mit dem Verzicht auf die besondere Flexibilität oder Direktheit der anderen Stile.

Kosten. Wo die Kommunikation doch die Form eines anderen Stils hat, muss man sie in REST etwas umständlicher nachbilden — der Preis der Schlichtheit.

Wann wir anders entscheiden. Wo die Kommunikation eindeutig die Form von Aktionen oder flexiblen, verbundenen Abfragen hat, ist REST der Umweg, und der passende Stil ist die bessere Wahl.

4. Wann GraphQL passt — und was es kostet

GraphQL ist die passende Wahl, wo die Flexibilität auf der Seite des Aufrufers einen echten Wert hat: wo viele verschiedene Aufrufer sehr verschiedene Ausschnitte derselben, stark verbundenen Daten brauchen, und wo das Zusammensuchen dieser Ausschnitte über viele einzelne Aufrufe teuer oder umständlich würde. Dort spielt GraphQL seine Stärke aus — der Aufrufer beschreibt seinen Bedarf, und das System liefert genau ihn, in einem Zug.

Schema: Wo ein Aufrufer sonst viele verbundene Dinge einzeln zusammensucht, holt eine flexible Abfrage genau das Gewünschte in einem Zug — das ist GraphQLs Fall, und nur dort lohnt sein Preis.

Diese Flexibilität hat einen Preis, der zum Zeitpunkt der Wahl leicht übersehen wird. Die Freiheit des Aufrufers verlagert Komplexität auf die Seite des Anbieters: Anfragen sind schwerer vorherzusagen, schwerer zwischenzuspeichern und schwerer gegen Missbrauch abzusichern, weil man nicht mehr weiß, was der Aufrufer verlangen wird. Der Betrieb wird anspruchsvoller, und das System braucht Vorkehrungen, die REST nicht braucht. GraphQL ist deshalb kein Ersatz für REST, sondern die richtige Wahl für einen bestimmten Fall — vielgestaltiger Datenbedarf über verbundene Daten — und ein teurer Umweg für alle anderen.

Trade-off. GraphQL kauft Flexibilität für den Aufrufer mit verlagerter Komplexität, schwererer Zwischenspeicherung und anspruchsvollerem Betrieb beim Anbieter.

Kosten. Die Freiheit der Anfrage verlangt zusätzliche Vorkehrungen gegen Unvorhersehbarkeit und Missbrauch, die man baut und pflegt.

Wann wir anders entscheiden. Wo der Datenbedarf einfach und vorhersehbar ist, bleibt GraphQLs Flexibilität ungenutzt, und man trägt nur ihren Preis — dann ist der schlichtere Stil überlegen.

5. Wann RPC die klarste Form ist

RPC ist die passende Wahl, wo die Kommunikation im Kern aus dem Ausführen von Aktionen besteht, nicht aus dem Abrufen von Dingen. Wo ein System ein anderes bittet, etwas zu tun — eine Berechnung anzustoßen, einen Vorgang auszulösen, eine Operation durchzuführen —, ist der direkte Aufruf einer benannten Funktion die ehrlichste Form. Man muss die Aktion nicht in die Sprache der Ressourcen übersetzen, in der sie sich unnatürlich ausdrückt, sondern benennt sie als das, was sie ist. Besonders in der Kommunikation zwischen Diensten desselben Systems, wo Direktheit und Effizienz zählen und kein fremdes Publikum bedient wird, ist RPC oft die schlichteste und klarste Wahl — dort wiegt seine engere Kopplung wenig, weil die beteiligten Dienste ohnehin zusammengehören und gemeinsam weiterentwickelt werden.

Der Preis von RPC ist die Kehrseite seiner Direktheit. Weil es enger an die aufgerufene Funktion bindet, ist die Kopplung zwischen den Systemen tendenziell fester, und der Stil ist weniger selbsterklärend für fremde Aufrufer als das verbreitete REST. Für eine öffentliche, breit genutzte Schnittstelle ist das ein Nachteil; für die interne Kommunikation zwischen Diensten, die zusammengehören, ist die festere Kopplung oft unerheblich und die Direktheit ein Gewinn. Wie bei den anderen Stilen entscheidet der Kontext: RPC glänzt dort, wo Aktionen im Vordergrund stehen und die Aufrufer bekannt sind.

Trade-off. RPC kauft Direktheit beim Ausführen von Aktionen mit einer tendenziell festeren Kopplung und geringerer Selbsterklärung für fremde Aufrufer.

Kosten. Die engere Bindung an die aufgerufene Funktion kann Änderungen an der Schnittstelle spürbarer machen, besonders wenn die Aufrufer nicht eng koordiniert sind.

Wann wir anders entscheiden. Für eine öffentliche Schnittstelle mit vielen unbekannten Aufrufern ist die Verbreitung und Selbsterklärung von REST meist wertvoller als die Direktheit von RPC.

6. Das Kriterium: die Form der Kommunikation

Alle drei Wege laufen auf ein einziges Kriterium zusammen: die Form der Kommunikation, die stattfinden soll. Dreht sich alles um benannte Dinge, die man abruft und ändert, ist REST die natürliche Wahl. Geht es um das Ausführen von Aktionen zwischen bekannten Systemen, ist RPC die klarste Form. Brauchen viele verschiedene Aufrufer flexible Ausschnitte stark verbundener Daten, ist GraphQL im Vorteil. Das Kriterium ist nicht die Mode, sondern die Frage, wer wen wie und wozu anspricht.

Zur Form der Kommunikation tritt eine zweite, oft unterschätzte Größe: was das Team beherrscht und was seine Aufrufer erwarten. Ein Stil, den viele kennen, senkt die Kosten, ein System über Jahre zu betreiben und seine Schnittstelle von fremden Entwicklern nutzen zu lassen. Ein reicherer, seltenerer Stil verlangt mehr Wissen auf beiden Seiten — beim Anbieter, der ihn betreibt, und beim Aufrufer, der ihn nutzt. Diese Wissenskosten sind real und dauerhaft, und sie sprechen im Zweifel für den verbreiteten Stil, es sei denn, die Form des Problems verlangt eindeutig einen anderen.

Die Lebensdauer verschärft dieses Kriterium um eine Vorsicht: Weil der Stil den Vertrag prägt und der Vertrag schwer zu ändern ist, wählt man im Zweifel den einfacheren, verbreiteteren Stil, den man in zehn Jahren noch versteht und besetzen kann. Ein reicherer Stil muss seinen Mehraufwand über die Lebensdauer rechtfertigen; tut er das nicht, ist die Schlichtheit die langlebigere Wahl. Wer nach der Form der Kommunikation und der Lebensdauer entscheidet, muss den Stil weder gegen die Mode verteidigen noch ihr folgen — er entscheidet nach der Sache.

Trade-off. Nach der Form der Kommunikation zu entscheiden verlangt, diese Form ehrlich zu benennen, statt dem vertrauten oder modischen Stil zu folgen.

Kosten. Das Kriterium zwingt zu einer differenzierten Antwort pro Schnittstelle statt zu einer bequemen Hausregel für alles.

Wann wir anders entscheiden. Wo eine äußere Vorgabe den Stil bestimmt — eine geforderte Kompatibilität, eine bestehende Landschaft —, tritt das Kriterium zurück, und man folgt der Vorgabe.

7. Typische Fehler

Die wiederkehrenden Muster, an denen die Stilwahl scheitert — fast alle sind Varianten davon, nach Mode statt nach Form zu entscheiden:

• Den Stil nach Zeitgeist wählen und eine Passungsfrage als Geschmacksfrage führen.
• REST für überholt halten und einen reicheren Stil wählen, wo die Schlichtheit genügt hätte.
• GraphQLs Flexibilität wählen, ohne den vielgestaltigen Datenbedarf zu haben, der sie rechtfertigt — und nur ihren Preis tragen.
• Die verlagerte Komplexität von GraphQL übersehen: schwerere Zwischenspeicherung, anspruchsvollerer Betrieb, Absicherung gegen Unvorhersehbarkeit.
• Aktionen in die Sprache der Ressourcen zwingen, wo ein direkter Aufruf die ehrlichere Form gewesen wäre.
• RPC für eine öffentliche Schnittstelle mit vielen unbekannten Aufrufern wählen, wo Verbreitung und Selbsterklärung mehr zählen.
• Das ganze System in einen Stil pressen, obwohl verschiedene Teile verschiedene Kommunikationsformen haben.
• Die Langlebigkeit des Stils übersehen und einen wählen, den man in Jahren schwer versteht oder besetzt.

8. Entscheidungs-Checkliste

Vor der Wahl des API-Stils der Reihe nach zu klären:

• Form der Kommunikation? Dreht sich alles um Dinge (REST), Aktionen (RPC) oder flexible Abfragen verbundener Daten (GraphQL)?
• Genügt REST? Löst der schlichteste, verbreitetste Stil das Problem — und ist ein reicherer Stil wirklich nötig?
• Flexibilität gebraucht? Bei GraphQL: gibt es viele Aufrufer mit sehr verschiedenem Bedarf an verbundenen Daten — oder bleibt die Flexibilität ungenutzt?
• Versteckte Kosten bedacht? Sind bei GraphQL die schwerere Zwischenspeicherung und der anspruchsvollere Betrieb, bei RPC die festere Kopplung eingerechnet?
• Öffentlich oder intern? Bedient die Schnittstelle viele unbekannte Aufrufer (eher REST) oder bekannte, zusammengehörige Dienste (RPC vertretbar)?
• Gemischtes System? Ist geprüft, ob verschiedene Teile verschiedene Stile verdienen, statt einen für alles?
• Langlebigkeit? Ist der Stil einer, den man über Jahre versteht und besetzen kann — und rechtfertigt ein reicherer seinen Mehraufwand?

Wer diese Fragen beantworten kann, hat den API-Stil nach der Form der Kommunikation gewählt — nicht nach dem, was gerade als modern gilt.

FAQ

Ist GraphQL der moderne Nachfolger von REST? Nein, es ist eine andere Form für einen anderen Fall. GraphQL glänzt, wo viele Aufrufer flexible Ausschnitte stark verbundener Daten brauchen; REST glänzt, wo es um das schlichte Abrufen und Ändern benannter Dinge geht. Das eine löst das andere nicht ab — sie passen zu verschiedenen Formen von Kommunikation. Für den häufigsten Fall genügt REST.

Warum ist REST für die meisten Systeme die richtige Wahl? Weil die meiste betriebliche Kommunikation im Kern darin besteht, benannte Dinge abzurufen und zu verändern — genau REsts Form. REST ist überall verstanden, gut zwischenspeicherbar und leicht zu betreiben. Seine Schlichtheit ist kein Mangel, sondern der Grund, warum es über Jahre trägt. Wo es genügt, ist ein reicherer Stil eine Verkomplizierung.

Was kostet GraphQL, das man leicht übersieht? Die Flexibilität des Aufrufers verlagert Komplexität auf den Anbieter: Anfragen sind schwerer vorherzusagen, schwerer zwischenzuspeichern und schwerer gegen Missbrauch abzusichern. Der Betrieb wird anspruchsvoller. Diese Kosten sind gut angelegt, wo der vielgestaltige Datenbedarf sie rechtfertigt, und verschwendet, wo er fehlt.

Wann ist RPC die richtige Wahl? Wo die Kommunikation aus dem Ausführen von Aktionen besteht, nicht aus dem Abrufen von Dingen — besonders zwischen Diensten desselben Systems, wo Direktheit zählt und kein fremdes Publikum bedient wird. Eine Aktion als benannten Funktionsaufruf auszudrücken ist ehrlicher, als sie in die Sprache der Ressourcen zu zwingen. Für öffentliche Schnittstellen ist REST meist die bessere Wahl.

Können wir mehrere Stile in einem System verwenden? Ja, und oft ist das richtig. Verschiedene Teile eines Systems haben verschiedene Kommunikationsformen — interne Dienste sprechen anders miteinander als eine öffentliche Schnittstelle mit ihren Aufrufern. Das ganze System in einen Stil zu pressen, weil ein Teil ihn braucht, zwingt den anderen Teilen eine Form auf, die nicht ihre ist.

Wie wähle ich für ein langlebiges System? Im Zweifel den einfacheren, verbreiteteren Stil, den man in zehn Jahren noch versteht und besetzen kann. Weil der Stil den schwer änderbaren Vertrag prägt, muss ein reicherer Stil seinen Mehraufwand über die Lebensdauer rechtfertigen. Tut er das nicht, ist die Schlichtheit die langlebigere Wahl.

Weiterführend

• API Design für langlebige Systeme — die Prinzipien des Vertrags, unabhängig vom gewählten Stil.
• API-Versionierung ohne Kunden zu brechen — wie man den Vertrag weiterentwickelt, in welchem Stil auch immer.
• Ausgereifte Technik vor Neuheit — warum der verbreitete, schlichte Stil oft die langlebigere Wahl ist.
• Serverseitiges Rendering oder SPA — eine verwandte Entscheidung, ebenso oft nach Mode statt nach Passung getroffen.

Grundlage ist die Batunet Engineering Method: nach der Form der Kommunikation entscheiden, das Schlichteste wählen, das trägt, dem Bedarf folgen statt der Mode.

Abschließendes Engineering-Prinzip

Der API-Stil ist kein Bekenntnis, sondern eine Anpassung an die Form der Kommunikation. REST, GraphQL und RPC sind drei Antworten auf drei verschiedene Fragen — Dinge abrufen, Aktionen ausführen, Daten flexibel abfragen —, und die Kunst besteht darin, die eigene Frage zu erkennen, bevor man die Antwort wählt. Für die breite Mitte betrieblicher Systeme lautet die Frage „Dinge abrufen und ändern", und dort ist die schlichte, verbreitete Antwort auch die langlebigste. Der Reiz, einen reicheren Stil zu wählen, weil er moderner wirkt, ist derselbe Reiz, dem man auch bei der Technik widersteht: Man wählt nicht das Aufregendste, sondern das Passendste — und das Passendste ist öfter das Schlichte, als der Zeitgeist glauben macht. Wer den Stil nach der Form der Kommunikation und der Lebensdauer wählt, hat eine Schnittstelle, die noch trägt und noch verstanden wird, wenn die Moden, die sie sonst bestimmt hätten, längst gewechselt sind.

Kein API-Stil ist modern oder überholt — jeder ist die Antwort auf eine bestimmte Form von Frage. Wer die eigene Frage kennt, braucht die Mode nicht.