REST vs GraphQL: Was ist der Unterschied und welches solltest du nutzen?

REST und GraphQL sind zwei Arten, eine API zu entwerfen, also die vereinbarte Weise, wie die Bildschirme deiner App (oder andere Programme) bei deinem Backend Daten anfragen. Bei REST gibt es für jede Art von Objekt eine eigene URL, etwa /customers oder /orders, und jede liefert eine festgelegte Datenstruktur. Bei GraphQL gibt es meist eine URL, und der Aufrufer schickt eine Abfrage, die genau auflistet, welche Felder zurückkommen sollen. Für die meisten Apps, die mit KI gebaut werden, ist REST der einfachere und bessere Standard.

Warum das beim Bauen mit KI wichtig ist

Wenn du einen KI-Builder um „eine App mit Backend“ bittest, muss er festlegen, wie Frontend und Backend miteinander sprechen. Du musst das nicht jedes Mal entscheiden, aber du wirst die Begriffe im Code, in der Dokumentation und bei der Anbindung externer Dienste sehen. Manche Dienste bieten nur einen Stil an: Viele Dienste stellen REST-APIs bereit, andere, etwa Shopify und GitHub, bieten auch GraphQL an oder bevorzugen es. Den Unterschied zu kennen hilft dir, zu verstehen, womit du es zu tun hast, und keine unnötige Komplexität hinzuzufügen. Wenn dir „API“ neu ist, beginne mit was eine API ist.

Ein Alltagsvergleich

REST ist ein Menü mit festen Gerichten. Jedes Gericht (Endpunkt) kommt so, wie die Küche es entworfen hat. Bestellst du das Gericht „Kunde“, bekommst du den ganzen Teller: Name, E-Mail, Adresse, Anmeldedatum, auch wenn du nur den Namen wolltest. Willst du auch die letzten Bestellungen des Kunden? Das ist ein zweites Gericht.

GraphQL ist à la carte bei einem Kellner. Du schreibst genau auf, was du willst: „den Namen des Kunden und Datum und Summe seiner letzten drei Bestellungen“. Eine Bestellung, ein Teller, nur das, was du angefragt hast. Doch die Küche muss so eingerichtet sein, dass sie jede Kombination verarbeiten kann, die Kunden aufschreiben.

Dieselbe Anfrage auf beide Arten

Angenommen, eine Kundenseite braucht den Namen eines Kunden und seine drei letzten Bestellungen.

Mit REST sind das typischerweise zwei Anfragen:

GET /api/customers/42
GET /api/customers/42/orders?limit=3

Die erste Antwort enthält womöglich mehr, als die Seite braucht:

{ "id": 42, "name": "Lena Park", "email": "lena@example.com", "address": "…", "createdAt": "…" }

Mit GraphQL ist es eine einzige Anfrage, meist ein POST an einen einzigen Endpunkt wie /graphql, mit einer Abfrage im Gepäck:

query {
  customer(id: 42) {
    name
    orders(last: 3) {
      date
      total
    }
  }
}

Und die Antwort spiegelt die Abfrage genau wider:

{
  "data": {
    "customer": {
      "name": "Lena Park",
      "orders": [
        { "date": "2026-09-20", "total": 48.0 },
        { "date": "2026-09-02", "total": 19.5 },
        { "date": "2026-08-15", "total": 72.25 }
      ]
    }
  }
}

Beide liefern JSON zurück. Der Unterschied liegt darin, wer die Form bestimmt: Bei REST macht das der Server; bei GraphQL bestimmt der Aufrufer sie, innerhalb dessen, was das Schema des Servers erlaubt.

Vergleich nebeneinander

Wo jede Variante passt

Wähle REST, wenn:

• du eine typische App baust: ein Buchungssystem, ein CRM, ein Dashboard, einen Shop.
• ein Frontend mit einem Backend spricht und du beide kontrollierst.
• du das Einfachste willst, das sich debuggen, cachen und absichern lässt.
• andere Dienste deine App aufrufen werden (Webhooks und die meisten Integrationen erwarten REST-artige Endpunkte).

Erwäge GraphQL, wenn:

• mehrere verschiedene Clients, etwa eine Website, eine mobile App und Partner-Integrationen, sehr unterschiedliche Ausschnitte derselben Daten brauchen.
• deine Daten stark verknüpft sind (Produkte, Varianten, Bewertungen, Verkäufer, Bestand) und Bildschirme sie auf vielfältige Weise kombinieren müssen.
• du einen Dienst nutzt, der GraphQL als Hauptschnittstelle anbietet.

Eine brauchbare Faustregel: Wenn du nicht sicher bist, ob du GraphQL brauchst, brauchst du es wahrscheinlich noch nicht. Es lässt sich leichter später hinzufügen als wieder entfernen.

Wichtige Begriffe

Häufige Missverständnisse

• „GraphQL ist neuer, also besser.“ Es löst bestimmte Probleme. Für eine einzelne App mit einem Frontend bringt es oft Mehraufwand ohne großen Nutzen.
• „GraphQL ist eine Datenbank.“ Ist es nicht. Es ist eine API-Schicht; dahinter liest der Server trotzdem aus deiner Datenbank.
• „GraphQL ist immer schneller.“ Weniger Anfragen können in langsamen Mobilfunknetzen helfen, aber eine unbegrenzte Abfrage kann riesige Datenmengen laden. Die Leistung hängt vom Backend ab.
• „REST bedeutet einen strengen Standard.“ In der Praxis heißt „REST-API“ lose: Ressourcen-URLs plus HTTP-Methoden und JSON. Viele gute APIs biegen die formalen Regeln.
• „Status 200 heißt, es hat funktioniert.“ Bei GraphQL prüfe das Feld errors. Eine Anfrage kann teilweise fehlschlagen und trotzdem 200 zurückgeben.

Was du deinen KI-Builder fragen solltest

• „Nutze eine einfache REST-API mit JSON, außer es gibt einen klaren Grund dagegen. Erkläre, wenn du meinst, dass GraphQL nötig ist.“
• „Liste jeden Endpunkt auf, was er zurückgibt und wer ihn aufrufen darf.“
• „Gib auf der Kundenseite nur die Felder zurück, die die Seite nutzt.“
• „Füge Seitennummerierung zu Listen-Endpunkten hinzu, damit sie nie tausende Zeilen auf einmal liefern.“
• „Dieser Dienst hat nur eine GraphQL-API. Rufe sie vom Server auf, halte den Schlüssel in einem Geheimnis und fordere nur die Felder an, die wir brauchen.“
• „Gib korrekte HTTP-Statuscodes und JSON-Fehlermeldungen zurück.“

REST und GraphQL in Mythex

Die Dokumentation von Mythex enthält ein Rezept für den Aufbau eines REST-API-Backends mit einem Start-Prompt. Ein Backend kann in Node, Python (FastAPI), C# oder Java neben deiner Web-App laufen. Die Dokumentation beschreibt keine GraphQL-Vorlage. Wenn du eine willst, fordere sie ausdrücklich an und nenne den Grund. Den Aufruf einer GraphQL-API eines Drittanbieters machst du wie bei jedem externen Dienst; siehe jede API einbinden. Weiterführend: Frontend vs. Backend und wie du eine REST-API baust.

Fragen