REST vs GraphQL: Welche API-Architektur für KI-Integrationen?

Was sind REST und GraphQL?

REST (Representational State Transfer) ist seit 2000 (Roy Fielding-Dissertation) das dominierende Architektur-Muster für Web-APIs. Eine REST-API stellt Ressourcen über URL-Pfade dar (/v1/invoices, /v1/contacts/123), nutzt HTTP-Verben für Operationen (GET, POST, PUT, DELETE) und transportiert in der Regel JSON über HTTPS. Mai 2026 sind über 80 Prozent aller produktiven APIs REST-basiert; alle in den vorigen Topics genannten Schnittstellen (Bexio, Microsoft Graph, Google Workspace) sind REST.

GraphQL (entwickelt bei Facebook ab 2012, open-source seit 2015) ist eine alternative Abfrage-Sprache für APIs. Statt vieler Endpunkte gibt es einen einzigen Endpoint (z.B. /graphql), der eine textuelle Query mit der gewünschten Datenstruktur entgegennimmt. Der Server gibt nur die angefragten Felder zurück, was Over- und Under-Fetching reduziert. GraphQL ist stark in komplexen, vernetzten Datenmodellen (Soziale Netze, Produkt-Kataloge mit vielen Beziehungen).

Die wichtigsten Spezifikationen Mai 2026: OpenAPI 3.1 (früher Swagger) für REST-Dokumentation, die maschinenlesbare Schema-Definition und Code-Generierung erlaubt. AsyncAPI 3 für Event-getriebene REST-Ergänzungen (Webhooks, Server-Sent Events, WebSockets). GraphQL hat sein eigenes Schema-Format (SDL, Schema Definition Language).

Für KI-Integrationen ist Mai 2026 eine dritte Schicht relevant: das Model Context Protocol (MCP), das Anthropic seit Ende 2024 etabliert hat. Ein MCP-Server ist ein Wrapper um eine bestehende REST- oder GraphQL-API, der LLMs einen standardisierten Zugang erlaubt. Statt jede LLM-Custom-Integration einzeln zu bauen, können Sie eine Bexio-MCP, eine SharePoint-MCP, eine Abacus-MCP bauen, und alle LLMs (Claude, GPT, Gemini, Mistral) können diese Server konsumieren.

Tools-Landschaft Mai 2026: FastAPI (Python) ist mit Abstand das beliebteste Framework für neue REST-APIs, vor allem für KI-getriebene Backends. Express bleibt der Klassiker in Node.js. tRPC ist ein TypeScript-Framework, das End-to-End-typsichere APIs zwischen Frontend und Backend baut, ohne explizites Schema. Hasura und PostGraphile generieren GraphQL-APIs automatisch aus einer Postgres-DB. Postman und Insomnia sind die führenden API-Test-Tools.

Warum es für CH-Treuhand wichtig ist

Eine CH-Treuhand-Stelle, die KI einführt, baut typischerweise eine Integrations-Schicht zwischen den Bestands-Systemen (Bexio, Abacus, Microsoft 365) und den KI-Komponenten (LLM, Embedding, Vektor-DB). Diese Schicht ist Ihre eigene API. Sie haben hier eine wichtige Entscheidung zu treffen: REST oder GraphQL.

Für 90 Prozent der CH-Treuhand-Setups ist REST die richtige Wahl. Gründe: (a) alle Quell-Systeme sind REST, ein REST-Adapter ist direkt. (b) REST-Frameworks (FastAPI, Express) sind erprobt, Hosting trivial. (c) OpenAPI 3.1 generiert automatisch Client-SDKs in Python, TypeScript, Java. (d) Caching ist mit Standard-Tools (Cloudflare, Varnish) trivial. (e) Debugging ist einfach: ein Browser plus curl reichen.

GraphQL lohnt sich, wenn (a) die Daten stark vernetzt sind (Mandant hat viele Rechnungen, jede Rechnung hat viele Positionen, jede Position hat viele Belege, etc.), (b) Frontends häufig Felder über mehrere Joins anfragen, und (c) das Team Erfahrung mit GraphQL hat. In klassischer Treuhand-Buchhaltung sind diese Bedingungen selten erfüllt.

Der dritte Layer, MCP, ist Mai 2026 die spannendste Entwicklung. Ein MCP-Server kapselt eine API in einer Form, die LLM-agnostisch ist. Sie bauen einen Bexio-MCP-Server einmal, und sowohl Claude (im Claude Desktop), GPT (in OpenAI Custom Apps) und Gemini können ihn nutzen. Das ist die natürliche Architektur für Treuhand-KI-Tools, die auf vielen LLM-Backends laufen sollen.

Wie es funktioniert

Eine REST-API hat einen typischen Aufbau: Endpoints für Ressourcen, HTTP-Verben für Aktionen, JSON als Transport, OpenAPI 3.1 als Schema. Beispiel mit FastAPI (Python):

```python from fastapi import FastAPI, Header from pydantic import BaseModel

app = FastAPI(title="Treuhand AI API", version="1.0")

class InvoiceQuery(BaseModel): client_id: int status: str = "open"

@app.get("/v1/invoices") def list_invoices(client_id: int, status: str = "open", authorization: str = Header(...)): # OAuth-Token aus Authorization-Header # Bexio-API aufrufen, Daten filtern return {"invoices": [...], "total": 42}

@app.post("/v1/ai/dunning-suggestion") def dunning_suggestion(query: InvoiceQuery): # KI-Vorschlag generieren return {"text": "...", "confidence": 0.85} ```

FastAPI generiert automatisch eine OpenAPI-Spec, einen Swagger-UI unter /docs und Redoc unter /redoc. Ein Client kann mit OpenAPI Generator in 30 Sekunden ein TypeScript-SDK erstellen.

Eine GraphQL-API hat einen einzelnen Endpoint und ein SDL-Schema:

```graphql type Invoice { id: ID! documentNr: String! total: Float! status: String! client: Client! }

type Query { invoices(clientId: ID!, status: String): [Invoice!]! dunningSuggestion(invoiceId: ID!): DunningSuggestion! } ```

Der Client sendet eine Query:

```graphql query { invoices(clientId: "123", status: "open") { documentNr total client { name email } } } ```

Der Server gibt nur die angefragten Felder zurück. Apollo Server oder GraphQL Yoga sind die gängigen Server-Implementierungen in Node.js, Strawberry oder Ariadne in Python.

Ein MCP-Server (Model Context Protocol) ist die LLM-getrennte Schicht. Sie definieren Tools, die ein LLM aufrufen kann:

```python from mcp.server import Server import mcp.types as types

server = Server("bexio-mcp")

@server.list_tools() async def list_tools() -> list[types.Tool]: return [ types.Tool( name="list_invoices", description="List open invoices for a client", inputSchema={"type": "object", "properties": {"client_id": {"type": "integer"}}} ) ]

@server.call_tool() async def call_tool(name: str, arguments: dict): if name == "list_invoices": # Bexio-API call return [...] ```

Der MCP-Server läuft als separater Prozess (z.B. via stdio oder SSE) und wird von Claude Desktop oder anderen MCP-Clients konsumiert.

API-Architektur-Entscheidung in 5 Schritten

1. 01Anforderungen klären: Welche Konsumenten gibt es (Frontend, Backend-Workflows, LLM), welche Latenz-Anforderung, welches Daten-Volumen?
2. 02Stack wählen: REST für 90% der Fälle, GraphQL nur bei stark vernetzten Datenmodellen, gRPC bei Service-zu-Service-Calls mit hoher Frequenz.
3. 03Framework wählen: FastAPI (Python) für KI-getriebene Backends, Express (Node) für JavaScript-Teams, tRPC für TypeScript-End-to-End.
4. 04OpenAPI-3.1-Schema von Anfang an pflegen, Code-Generator nutzen für Client-SDKs in Python und TypeScript.
5. 05MCP-Server als zusätzliche Schicht erwaegen, sobald LLM-Zugriff auf interne Daten geplant ist, für LLM-agnostischen Zugang.

Wann was einsetzen

REST ist die richtige Wahl in praktisch allen Treuhand-Szenarien. Sie integrieren bestehende REST-APIs, bauen darüber eine eigene REST-Schicht und lassen Frontends oder Workflows diese konsumieren. FastAPI mit Python ist Mai 2026 die produktivste Wahl, weil die meisten KI-Bibliotheken (OpenAI SDK, Anthropic SDK, LangChain, LlamaIndex) Python-nativ sind und in FastAPI direkt integriert werden können.

GraphQL lohnt sich nur in spezifischen Fällen: Frontends mit vielen verschachtelten Datenstrukturen, mobile Apps mit Bandbreiten-Beschränkung, oder bestehende GraphQL-Infrastruktur im Konzern.

MCP-Server lohnen sich, sobald (a) Sie ein KI-Werkzeug bauen, das mehrere LLMs unterstützen soll, oder (b) Sie sich eine Option offen halten wollen, das LLM in Zukunft zu wechseln (etwa von Claude zu Mistral für DSG-Sensitivität). Der Aufwand eines MCP-Wrappers ist gering (typisch 1-3 Tage), die Flexibilität hoch.

Für LLM-getriebene Datenbank-Zugriffe (etwa "schreibe eine SQL-Query") ist tRPC eine elegante Wahl: Sie schreiben die Typen einmal, der Client erhält sie via TypeScript-Inference, kein separates Schema-Mapping nötig.

Wann NICHT

GraphQL ist falsch bei einfachen CRUD-Apps (wenige Endpoints, klare Ressourcen). Der Overhead der Schema-Definition und der GraphQL-Server-Logik ist disproportioniert zum Nutzen.

REST ist falsch bei sehr realzeit-kritischen Anwendungen mit komplexen Push-Patterns (Online-Kollaboration, Live-Boerse). Hier sind WebSockets, Server-Sent Events oder gRPC besser.

MCP-Server sind heute (Mai 2026) noch jung. Wenn Sie ein streng auf eine LLM-Plattform getrimmtes Werkzeug bauen (etwa eine Claude-Custom-App für eine spezifische Branche), ist Direktintegration über Anthropic Tool Use einfacher. MCP wird mit der Zeit Standard, ist aber Stand Mai 2026 noch in der Etablierungs-Phase ausserhalb des Claude-Ökosystems.

Für rein interne Skripte (etwa ein nightly Cron, der CSV-Daten aus einer Excel exportiert) brauchen Sie weder REST noch GraphQL. Ein direkter Python- oder Node-Skript reicht.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. OpenAPI Initiative: OpenAPI Specification 3.1 · 2026-05
2. GraphQL Specification (current draft May 2026) · 2026-05
3. Anthropic: Model Context Protocol (MCP) Specification · 2026-05
4. FastAPI documentation · 2026-04