API-Architekturen im Überblick

Worum geht's?

„API" ist ein Sammelbegriff für sehr unterschiedliche Kommunikationsmuster. Manche sind synchron, manche streamen, manche pushen. Dieser Guide ordnet die gängigen API-Architekturen ein – mit klaren Vor- und Nachteilen und konkreten Einsatzgebieten. Ein passender Laravel-Implementierungs-Guide liegt unter Laravel-API-Guide.

1. Schnell-Entscheidungshilfe

Du willst…	Nimm
CRUD über Ressourcen, einfache Web-API	REST
Flexible Queries, mehrere Clients (Web/Mobile)	GraphQL
Hochperformante Service-zu-Service-Kommunikation	gRPC
Echtzeit-Bidirektional (Chat, Multiplayer)	WebSocket
Server-zu-Client-Stream (Notifications, Tickers)	Server-Sent Events
Event-Push an Drittsysteme	Webhooks
Type-safe End-to-End in TypeScript-Monorepo	tRPC
Legacy-Enterprise-Integration (Banken, ERP)	SOAP
Simple Remote-Procedure-Call	JSON-RPC
Async-Message-Bus, entkoppelte Services	Message Queue / Event Streaming

2. Die Architektur-Landkarte

┌──────────────────────────────────────────────────────────────────────────────┐
│                          SYNCHRON / REQUEST-RESPONSE                         │
├──────────────────────────────────────────────────────────────────────────────┤
│  REST    │  GraphQL  │  gRPC     │  SOAP     │  JSON-RPC │  tRPC            │
│  HTTP    │  HTTP     │  HTTP/2   │  HTTP/XML │  HTTP     │  HTTP            │
│  Ressrc. │  Query    │  Proto    │  WSDL     │  Methode  │  TS-Function     │
└──────────────────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────────────────┐
│                                STREAMING                                     │
├──────────────────────────────────────────────────────────────────────────────┤
│  WebSocket          │  Server-Sent Events │  gRPC-Streaming                  │
│  bidirektional      │  Server → Client    │  bi/uni-direktional              │
└──────────────────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────────────────┐
│                              EVENT-DRIVEN                                    │
├──────────────────────────────────────────────────────────────────────────────┤
│  Webhooks    │  Message Queue (RabbitMQ, SQS)  │  Event Streaming (Kafka)   │
│  HTTP-Push   │  Producer → Consumer            │  Append-Only Log           │
└──────────────────────────────────────────────────────────────────────────────┘

3. REST (Representational State Transfer)

Was es ist: Der De-facto-Standard für Web-APIs. Ressourcen als URLs, HTTP-Methoden als Verben, JSON als Payload.

GET    /api/users          → Liste
GET    /api/users/42       → Einzelressource
POST   /api/users          → Neu anlegen
PUT    /api/users/42       → Komplett ersetzen
PATCH  /api/users/42       → Teil-Update
DELETE /api/users/42       → Löschen

Vorteile

Universell verstanden – jede Sprache, jeder Browser, jedes Tool
Caching out of the box über HTTP-Cache-Header
Einfach zu testen mit curl, Postman, Browser
Stateless – horizontal skalierbar ohne Sticky Sessions
Riesiges Tooling: OpenAPI/Swagger, Postman, Insomnia

Nachteile

Over-/Under-Fetching: Clients holen oft zu viel oder zu wenig pro Request
N+1-Requests bei verschachtelten Ressourcen
Versionierung umständlich: /v1/, /v2/ oder Header
Keine Typsicherheit zwischen Server und Client (ohne OpenAPI-Codegen)

Einsatzgebiete

Öffentliche Web-APIs (Stripe, GitHub, Shopify)
Klassische CRUD-Backends
Mobile-/SPA-Backends mittlerer Komplexität
Microservices mit moderater Performance-Anforderung

4. GraphQL

Was es ist: Eine Query-Sprache. Der Client beschreibt exakt, welche Felder er braucht, der Server liefert nur diese.

query {
  user(id: 42) {
    name
    email
    orders(last: 5) {
      id
      total
    }
  }
}

Vorteile

Kein Over-/Under-Fetching – Client steuert die Form
Eine Query, viele Ressourcen – ersetzt mehrere REST-Aufrufe
Typsicheres Schema als Single Source of Truth
Selbstdokumentierend via Introspection (GraphiQL, Apollo Studio)
Subscriptions für Echtzeit-Updates (über WebSocket)

Nachteile

Caching aufwendiger – HTTP-Cache funktioniert nicht out of the box
N+1-Falle im Resolver – DataLoader-Pattern Pflicht
Query-Komplexität kann den Server killen – Depth-/Cost-Limits nötig
File Uploads kompliziert
Lernkurve für Team und Tools

Einsatzgebiete

BFF (Backend-for-Frontend) für mehrere Clients
Mobile-Apps mit variablen View-Anforderungen
Aggregations-Layer über viele Microservices
Produkte mit häufig wechselndem UI (z. B. Marketplace, Dashboards)

Bekannte Nutzer: GitHub, Shopify, Facebook, Twitter API v2

5. gRPC

Was es ist: Google's RPC-Framework über HTTP/2 mit Protocol Buffers als Wire-Format. Binär, schnell, typsicher.

service UserService {
  rpc GetUser (UserRequest) returns (User);
  rpc StreamOrders (OrderFilter) returns (stream Order);
}

message User {
  int32 id = 1;
  string name = 2;
}

Vorteile

Sehr schnell: Binärformat, HTTP/2-Multiplexing
Echte Typsicherheit via .proto-Files, Codegen für 10+ Sprachen
Streaming nativ: Unary, Server-Stream, Client-Stream, Bidirectional
Schemata sind Pflicht – kein „Wildwuchs"
Polyglott: Go ↔ Java ↔ Python ↔ Rust ↔ Node mit denselben Schnittstellen

Nachteile

Schwer im Browser (gRPC-Web als Krücke, oft mit Envoy-Proxy)
Binär → nicht im Browser debugbar ohne extra Tools
Steile Lernkurve für Teams ohne Proto-Erfahrung
HTTP-Caching entfällt

Einsatzgebiete

Service-zu-Service in Microservice-Architekturen
Performance-kritische interne APIs
IoT-Geräte mit schmalbandiger Verbindung
Multi-Sprach-Backend-Landschaften

Bekannte Nutzer: Google intern, Netflix, Square, Cilium, etcd, Kubernetes

6. WebSocket

Was es ist: Persistente, bidirektionale TCP-Verbindung über HTTP-Upgrade. Server und Client können jederzeit Nachrichten pushen.

Vorteile

Echtzeit-Bidirektional mit niedriger Latenz
Sehr geringe Overhead pro Nachricht (keine HTTP-Header je Frame)
Browser-nativ (new WebSocket(...))
Perfekt für Chats, Games, Live-Editing, Trading

Nachteile

Zustandsbehaftet – Sticky Sessions oder Pub/Sub-Bus nötig
Skalierung anspruchsvoll – jede Verbindung belegt Server-Memory
Reconnect-Logik im Client Pflicht
HTTP-Proxies/Firewalls machen manchmal Ärger
Kein eingebautes Backpressure – muss man selbst bauen

Einsatzgebiete

Chat-Anwendungen (Slack, Discord)
Collaborative Editing (Figma, Google Docs Cursors)
Live-Dashboards, Stock-Ticker
Online-Multiplayer-Games
Realtime-Benachrichtigungen mit User-Interaktion

Frameworks: Socket.IO, Pusher, Soketi, Laravel Reverb, Ably

7. Server-Sent Events (SSE)

Was es ist: HTTP-Stream, bei dem der Server kontinuierlich Events an den Client sendet. Einseitig (Server → Client).

GET /events
Content-Type: text/event-stream

data: {"price": 42}

data: {"price": 43}

Vorteile

Über reguläres HTTP – funktioniert mit jedem Proxy, jedem Load Balancer
Auto-Reconnect im Browser eingebaut (EventSource)
Sehr einfach zu implementieren – fast wie ein langer Response
Kein neues Protokoll – HTTP-Caching/Auth funktioniert
Perfekt für LLM-Streaming (ChatGPT, Claude UI nutzen SSE)

Nachteile

Einseitig – Client kann nicht über denselben Channel pushen
Browser-Limit: 6 SSE-Verbindungen pro Domain (HTTP/1.1)
PHP/Laravel brauchen Long-Running-Worker oder Reverb-Setup

Einsatzgebiete

LLM-Output-Streaming (ChatGPT, Claude)
Live-Notifications (Inbox, Alerts)
Progress-Updates für lange Jobs
Activity-Feeds, Stock-Prices

8. Webhooks

Was es ist: Reverse-API. Statt zu pollen, registriert der Client eine URL – der Server ruft sie an, wenn ein Event eintritt.

Stripe → POST https://example.com/webhooks/stripe
       Body: { "type": "payment.succeeded", ... }

Vorteile

Push statt Poll – sofortige Reaktion, kein Lastpolling
Einfach zu implementieren – nur eine HTTP-Endpoint nötig
Lose Kopplung zwischen Systemen

Nachteile

Empfänger muss öffentlich erreichbar sein (oder Tunnel: ngrok, smee.io)
Retry/Delivery-Garantien je nach Anbieter unterschiedlich
Signature-Verifikation Pflicht (sonst Spoofing)
Idempotenz muss eigener Empfänger-Code sicherstellen

Einsatzgebiete

Payment-Provider (Stripe, PayPal, Mollie)
Git-Plattformen (GitHub, GitLab → CI-Trigger)
SaaS-Integrationen (Slack-Events, Zapier)
Mailservices (SendGrid, Postmark Delivery-Status)

9. SOAP

Was es ist: XML-basiertes, schwergewichtiges RPC-Protokoll mit WSDL-Schema. Aus der Web-1.0-Ära, aber in Enterprise und Behörden noch sehr lebendig.

<soap:Envelope>
  <soap:Body>
    <getUser>
      <id>42</id>
    </getUser>
  </soap:Body>
</soap:Envelope>

Vorteile

Strict Schema via WSDL
WS-Security, WS-Transactions – Enterprise-Features eingebaut
In Banken, Versicherungen, Behörden Standard

Nachteile

Verbose XML – riesige Payloads
Steile Lernkurve, schwierig zu debuggen
Tooling stirbt langsam außerhalb von Java/.NET
Kein Browser-Friendly-Pattern

Einsatzgebiete

Banken-Schnittstellen, Versicherungs-EAI
Legacy-ERP-Systeme (SAP-PI)
Behörden-Web-Services (z. B. ELSTER, EU-Plattformen)
Wenn das Gegenüber es so verlangt – Punkt.

10. JSON-RPC

Was es ist: Schlankes RPC-Protokoll, das JSON statt XML nutzt. Eine Methode + Parameter + Response.

{
  "jsonrpc": "2.0",
  "method": "getUser",
  "params": { "id": 42 },
  "id": 1
}

Vorteile

Sehr einfach – nur 3 Felder Pflicht
Batch-Requests nativ
Notifications (Fire-and-Forget) eingebaut
Transport-agnostisch – HTTP, WebSocket, raw TCP

Nachteile

Keine REST-Konventionen – Caching, Status-Codes weniger natürlich
Weniger Tooling als REST/GraphQL
Versionierung selbst lösen

Einsatzgebiete

Ethereum/Bitcoin-Nodes (Standard-Wallet-API)
Language-Server-Protokoll (LSP), Debug-Adapter-Protokoll
Bridged WebSocket-RPCs in Trading-Plattformen

11. tRPC

Was es ist: Type-safe RPC für TypeScript-Monorepos. Server-Funktionen werden im Client wie lokale Funktionen aufgerufen – mit voller Typsicherheit, ohne Codegen.

// Server
export const appRouter = router({
  getUser: publicProcedure
    .input(z.object({ id: z.number() }))
    .query(({ input }) => db.user.findUnique({ where: { id: input.id } }))
});

// Client
const user = await trpc.getUser.query({ id: 42 });  // Autocomplete + Typen!

Vorteile

End-to-end-Typsicherheit ohne separates Schema
Kein Codegen-Schritt
Subscriptions, Batching, Caching out of the box
Sehr produktiv in Next.js/Remix-Monorepos

Nachteile

Nur TypeScript zu TypeScript
Nicht öffentlich konsumierbar – keine OpenAPI-Doku, keine externen Clients
Vendor-Bindung an JS-Ökosystem

Einsatzgebiete

Full-Stack-TS-Apps (Next.js, Remix, T3-Stack)
Interne Tools mit kleinem Team
Schnelle Prototypen mit Type-Safety

12. Message Queues & Event Streaming

Was es ist: Asynchrone Kommunikation. Producer schreibt Nachrichten in eine Queue/Stream, Consumer liest sie unabhängig.

	Queue (RabbitMQ, SQS, Redis)	Stream (Kafka, Redpanda, Pulsar)
Modell	Punkt-zu-Punkt	Publish-Subscribe, Append-Only-Log
Persistenz	bis Consume	Tage/Wochen, Replay möglich
Reihenfolge	per Queue garantiert	per Partition
Stärken	Einfach, Job-Workers	Event-Sourcing, Replay, hohe Durchsätze

Vorteile

Entkopplung von Producer und Consumer
Lastspitzen abfedern durch Pufferung
At-least-once-Delivery mit Retries
Skalierung horizontal über Consumer Groups
Audit-Trail (insbes. Kafka-Streams)

Nachteile

Eventual Consistency – keine synchronen Antworten
Betriebs-Overhead (Kafka, RabbitMQ sind eigene Systeme)
Debugging schwerer – Nachrichten verteilen sich über mehrere Services
Idempotenz muss im Consumer gelöst sein

Einsatzgebiete

Hintergrund-Jobs (E-Mails, Bildverarbeitung, PDF-Generation)
Inter-Service-Events (Order-Created → Inventory, Shipping, Billing)
Event-Sourcing-Architekturen
ETL-Pipelines, Analytics-Streams

13. Große Vergleichstabelle

Architektur	Latenz	Durchsatz	Typsicherheit	Browser	Streaming	Caching	Lernkurve
REST	mittel	mittel	über OpenAPI	✅	⚪	✅	flach
GraphQL	mittel	mittel	✅	✅	✅ (Subs)	tlw.	steil
gRPC	sehr niedrig	hoch	✅ Proto	⚪ (Web-Proxy)	✅	⚪	steil
WebSocket	sehr niedrig	hoch	–	✅	✅	⚪	mittel
SSE	niedrig	mittel	–	✅	✅ einseitig	⚪	flach
Webhooks	n. a.	n. a.	–	n. a.	⚪	n. a.	flach
SOAP	hoch	niedrig	✅ WSDL	⚪	⚪	⚪	sehr steil
JSON-RPC	mittel	mittel	–	✅	tlw.	⚪	flach
tRPC	mittel	mittel	✅ via TS	✅	✅	✅	flach (TS)
Queues/Streams	async	sehr hoch	tlw. (Avro/Proto)	⚪	n. a.	n. a.	mittel–steil

14. Auswahl-Heuristik

„Ich baue eine öffentliche API."

→ REST mit OpenAPI-Spec. Wenn flexible Queries kritisch: GraphQL.

„Microservices intern, hohe Performance."

→ gRPC. Für Events zusätzlich Kafka/RabbitMQ.

„Chat, Multiplayer, Collab-Editing."

→ WebSocket (Laravel: Reverb, Pusher, Soketi).

„LLM-Streaming, Notifications."

→ SSE. Einfacher als WebSocket und vollkommen ausreichend.

„Drittsystem soll mich aktiv informieren."

→ Webhooks mit HMAC-Signatur.

„Full-Stack-TS-App, Solo oder kleines Team."

→ tRPC. Maximale Produktivität.

„Bank/Versicherung verlangt es."

→ SOAP. Punkt.

„Hintergrund-Jobs, hohe Last."

→ Queue (Redis/SQS) für Jobs, Kafka für Event-Sourcing.

15. Sicherheits-Querschnitt

Gilt für ALLE API-Architekturen

Authentication: JWT, OAuth2, API-Keys – nie selbst Crypto bauen
Authorization: Pro Endpoint/Methode/Topic prüfen, nicht nur Login
Rate Limiting auf Anbieter- und Nutzer-Ebene
Input-Validation strikt – Zod, FormRequests, JSON-Schemas
TLS überall, auch intern
CORS explizit konfigurieren, nie * für Auth-Endpoints
Webhook-Signaturen (HMAC) bei eingehenden Webhooks immer verifizieren
GraphQL: Query-Depth- und Cost-Limits, Persisted Queries
WebSocket: Auth beim Upgrade-Handshake, nicht erst pro Message
gRPC: mTLS für interne Service-Calls

16. Praktischer Kombi-Stack

┌─────────────────────────────────────────────────────────────────┐
│ Public API (Mobile + 3rd Party)                                 │
│   └─ REST + OpenAPI                  versioniert, dokumentiert  │
├─────────────────────────────────────────────────────────────────┤
│ Web-Frontend (SPA / Next.js)                                    │
│   └─ GraphQL oder tRPC               typsicher, flexibel        │
├─────────────────────────────────────────────────────────────────┤
│ Service-zu-Service                                              │
│   └─ gRPC                            schnell, typsicher         │
├─────────────────────────────────────────────────────────────────┤
│ Echtzeit-UI                                                     │
│   └─ WebSocket (Reverb) / SSE        Live-Updates               │
├─────────────────────────────────────────────────────────────────┤
│ Hintergrund-Jobs / Events                                       │
│   └─ Queue (Redis/SQS) + Kafka       async, entkoppelt          │
├─────────────────────────────────────────────────────────────────┤
│ Eingehende 3rd-Party-Events                                     │
│   └─ Webhooks (Stripe, GitHub, …)    HMAC-verifiziert           │
└─────────────────────────────────────────────────────────────────┘

17. Weiterführend

Laravel-Implementierung jeder Architektur → Laravel-API-Guide
OpenAPI / Swagger Playground → API Playground

Externe Quellen

Quote

„Architekturen wählt man nicht nach Mode, sondern nach Kommunikationsmuster, Konsistenzanforderung und Team-Skill."

1. Schnell-Entscheidungshilfe​

2. Die Architektur-Landkarte​

3. REST (Representational State Transfer)​

Vorteile​

Nachteile​

Einsatzgebiete​

4. GraphQL​

Vorteile​

Nachteile​

Einsatzgebiete​

5. gRPC​

Vorteile​

Nachteile​

Einsatzgebiete​

6. WebSocket​

Vorteile​

Nachteile​

Einsatzgebiete​

7. Server-Sent Events (SSE)​

Vorteile​

Nachteile​

Einsatzgebiete​

8. Webhooks​

Vorteile​

Nachteile​

Einsatzgebiete​

9. SOAP​

Vorteile​

Nachteile​

Einsatzgebiete​

10. JSON-RPC​

Vorteile​

Nachteile​

Einsatzgebiete​

11. tRPC​

Vorteile​

Nachteile​

Einsatzgebiete​

12. Message Queues & Event Streaming​

Vorteile​

Nachteile​

Einsatzgebiete​

13. Große Vergleichstabelle​

14. Auswahl-Heuristik​

„Ich baue eine öffentliche API."​

„Microservices intern, hohe Performance."​

„Chat, Multiplayer, Collab-Editing."​

„LLM-Streaming, Notifications."​

„Drittsystem soll mich aktiv informieren."​

„Full-Stack-TS-App, Solo oder kleines Team."​

„Bank/Versicherung verlangt es."​

„Hintergrund-Jobs, hohe Last."​

15. Sicherheits-Querschnitt​

16. Praktischer Kombi-Stack​

17. Weiterführend​

1. Schnell-Entscheidungshilfe

2. Die Architektur-Landkarte

3. REST (Representational State Transfer)

Vorteile

Nachteile

Einsatzgebiete

4. GraphQL

Vorteile

Nachteile

Einsatzgebiete

5. gRPC

Vorteile

Nachteile

Einsatzgebiete

6. WebSocket

Vorteile

Nachteile

Einsatzgebiete

7. Server-Sent Events (SSE)

Vorteile

Nachteile

Einsatzgebiete

8. Webhooks

Vorteile

Nachteile

Einsatzgebiete

9. SOAP

Vorteile

Nachteile

Einsatzgebiete

10. JSON-RPC

Vorteile

Nachteile

Einsatzgebiete

11. tRPC

Vorteile

Nachteile

Einsatzgebiete

12. Message Queues & Event Streaming

Vorteile

Nachteile

Einsatzgebiete

13. Große Vergleichstabelle

14. Auswahl-Heuristik

„Ich baue eine öffentliche API."

„Microservices intern, hohe Performance."

„Chat, Multiplayer, Collab-Editing."

„LLM-Streaming, Notifications."

„Drittsystem soll mich aktiv informieren."

„Full-Stack-TS-App, Solo oder kleines Team."

„Bank/Versicherung verlangt es."

„Hintergrund-Jobs, hohe Last."

15. Sicherheits-Querschnitt

16. Praktischer Kombi-Stack

17. Weiterführend