REST vs GraphQL: which API architecture for AI integrations?

What are REST and GraphQL?

REST (Representational State Transfer) has been the dominant architecture pattern for web APIs since 2000 (Roy Fieldings dissertation). A REST API exposes resources via URL paths (/v1/invoices, /v1/contacts/123), uses HTTP verbs for operations (GET, POST, PUT, DELETE), and usually transports JSON over HTTPS. As of May 2026, over 80 percent of all productive APIs are REST-based; all interfaces named in the previous topics (Bexio, Microsoft Graph, Google Workspace) are REST.

GraphQL (developed at Facebook from 2012, open-source since 2015) is an alternative query language for APIs. Instead of many endpoints there is a single endpoint (e.g. /graphql) that accepts a textual query with the desired data structure. The server returns only the requested fields, which reduces over- and under-fetching. GraphQL is strong in complex, networked data models (social networks, product catalogues with many relations).

The most important specifications May 2026: OpenAPI 3.1 (formerly Swagger) for REST documentation, allowing machine-readable schema definition and code generation. AsyncAPI 3 for event-driven REST extensions (webhooks, server-sent events, WebSockets). GraphQL has its own schema format (SDL, schema definition language).

For AI integrations, a third layer is relevant as of May 2026: the Model Context Protocol (MCP), which Anthropic established at the end of 2024. An MCP server is a wrapper around an existing REST or GraphQL API that gives LLMs standardised access. Instead of building each LLM custom integration one by one, you can build a Bexio MCP, a SharePoint MCP, an Abacus MCP, and all LLMs (Claude, GPT, Gemini, Mistral) can consume these servers.

Tools landscape May 2026: FastAPI (Python) is by far the most popular framework for new REST APIs, especially for AI-driven backends. Express remains the classic in Node.js. tRPC is a TypeScript framework that builds end-to-end type-safe APIs between frontend and backend without explicit schema. Hasura and PostGraphile auto-generate GraphQL APIs from a Postgres DB. Postman and Insomnia are the leading API test tools.

Why it matters for Swiss fiduciary

A Swiss fiduciary office introducing AI typically builds an integration layer between existing systems (Bexio, Abacus, Microsoft 365) and the AI components (LLM, embedding, vector DB). This layer is your own API. You have an important decision here: REST or GraphQL.

For 90 percent of Swiss fiduciary setups, REST is the right choice. Reasons: (a) all source systems are REST, a REST adapter is direct. (b) REST frameworks (FastAPI, Express) are proven, hosting is trivial. (c) OpenAPI 3.1 automatically generates client SDKs in Python, TypeScript, Java. (d) Caching is trivial with standard tools (Cloudflare, Varnish). (e) Debugging is easy: a browser plus curl is enough.

GraphQL is worthwhile when (a) the data is highly networked (client has many invoices, each invoice has many positions, each position has many receipts, etc.), (b) frontends frequently request fields over multiple joins, and (c) the team has GraphQL experience. In classic fiduciary bookkeeping these conditions are rarely met.

The third layer, MCP, is the most exciting development in May 2026. An MCP server wraps an API in a form that is LLM-agnostic. You build a Bexio MCP server once, and Claude (in Claude Desktop), GPT (in OpenAI custom apps), and Gemini can all use it. This is the natural architecture for fiduciary AI tools that should run on multiple LLM backends.

How it works

A REST API has a typical structure: endpoints for resources, HTTP verbs for actions, JSON as transport, OpenAPI 3.1 as schema. Example with FastAPI (Python):

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

app = FastAPI(title="Fiduciary 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 from Authorization header # Call Bexio API, filter data return {"invoices": [...], "total": 42}

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

FastAPI automatically generates an OpenAPI spec, a Swagger UI at /docs, and Redoc at /redoc. A client can create a TypeScript SDK in 30 seconds with OpenAPI Generator.

A GraphQL API has a single endpoint and an 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! } ```

The client sends a query:

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

The server returns only the requested fields. Apollo Server or GraphQL Yoga are the common server implementations in Node.js, Strawberry or Ariadne in Python.

An MCP server (Model Context Protocol) is the LLM-decoupled layer. You define tools an LLM can call:

```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 [...] ```

The MCP server runs as a separate process (e.g. via stdio or SSE) and is consumed by Claude Desktop or other MCP clients.

API architecture decision in 5 steps

1. 01Clarify requirements: which consumers exist (frontend, backend workflows, LLM), which latency requirement, which data volume?
2. 02Choose the stack: REST for 90% of cases, GraphQL only with highly networked data models, gRPC for high-frequency service-to-service calls.
3. 03Choose the framework: FastAPI (Python) for AI-driven backends, Express (Node) for JavaScript teams, tRPC for TypeScript end-to-end.
4. 04Maintain an OpenAPI 3.1 schema from the start, use a code generator for client SDKs in Python and TypeScript.
5. 05Consider an MCP server as an additional layer as soon as LLM access to internal data is planned, for LLM-agnostic access.

When to use what

REST is the right choice in practically all fiduciary scenarios. You integrate existing REST APIs, build your own REST layer on top, and let frontends or workflows consume it. FastAPI with Python is the most productive choice in May 2026 because most AI libraries (OpenAI SDK, Anthropic SDK, LangChain, LlamaIndex) are Python-native and integrate directly with FastAPI.

GraphQL pays off only in specific cases: frontends with many nested data structures, mobile apps with bandwidth constraints, or existing GraphQL infrastructure in the corporate group.

MCP servers pay off as soon as (a) you build an AI tool intended to support multiple LLMs, or (b) you want to keep the option open to switch the LLM in future (e.g. from Claude to Mistral for FADP sensitivity). The effort of an MCP wrapper is small (typically 1-3 days), the flexibility high.

For LLM-driven database access (such as "write a SQL query") tRPC is an elegant choice: you write the types once, the client receives them via TypeScript inference, no separate schema mapping required.

When not to use

GraphQL is wrong for simple CRUD apps (few endpoints, clear resources). The overhead of schema definition and GraphQL server logic is disproportionate to the benefit.

REST is wrong for very real-time-critical applications with complex push patterns (online collaboration, live trading). Here WebSockets, Server-Sent Events, or gRPC are better.

MCP servers are still young as of May 2026. If you build a tool strictly tuned to one LLM platform (such as a Claude custom app for a specific industry), direct integration via Anthropic Tool Use is simpler. MCP will become standard over time but is still in the establishment phase outside the Claude ecosystem as of May 2026.

For purely internal scripts (such as a nightly cron exporting CSV data from an Excel) you need neither REST nor GraphQL. A direct Python or Node script is enough.

Trade-offs

FAQ

Related topics

Sources

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