API Gateway vs. Reverse Proxy: Unterschiede und Einsatzszenarien

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

API Gateway und Reverse Proxy werden oft verwechselt, denn beide sitzen zwischen Client und Server und leiten Anfragen weiter. Aber sie lösen unterschiedliche Probleme auf unterschiedlichen Abstraktionsebenen. Wer den Unterschied nicht kennt, baut entweder zu viel Logik in den falschen Layer oder verzichtet auf Funktionen, die er braucht.

Was ist ein Reverse Proxy?

Ein Reverse Proxy ist ein Server, der zwischen Clients und einem oder mehreren Backend-Servern sitzt und eingehende Anfragen an die Backend-Server weiterleitet. Aus Sicht des Clients sieht der Reverse Proxy aus wie der eigentliche Server — der Client weiß nicht, welche Backend-Instanz die Anfrage tatsächlich bearbeitet.

Der Begriff “Reverse” bedeutet: Im Gegensatz zu einem Forward Proxy, der für den Client arbeitet und Anfragen nach außen weiterleitet, arbeitet der Reverse Proxy für den Server und nimmt Anfragen von außen entgegen.

Kernfunktionen eines Reverse Proxy

• Routing: Anfragen an unterschiedliche Backend-Server basierend auf URL-Pfaden oder Hostnamen weiterleiten
• Load Balancing: Anfragen auf mehrere Backend-Instanzen verteilen (Round-Robin, Least-Connections, IP-Hash)
• TLS Termination: SSL/TLS-Verbindung am Proxy beenden, Backend kommuniziert unverschlüsselt im internen Netz
• Caching: Statische Inhalte oder API-Antworten zwischenspeichern
• Compression: Antworten komprimieren (gzip, brotli) bevor sie zum Client gesendet werden
• Rate Limiting: Einfache Anfragelimits pro IP
• Health Checks: Backend-Server überwachen und bei Ausfall aus dem Pool entfernen

Bekannte Reverse Proxy Lösungen

• Nginx: Der am weitesten verbreitete Reverse Proxy, hochperformant, konfigurierbar
• HAProxy: Spezialisiert auf Load Balancing, TCP- und HTTP-Ebene
• Apache mit mod_proxy: Klassischer Webserver mit Proxy-Funktionalität
• Traefik: Moderner, Cloud-native Reverse Proxy mit automatischer Service Discovery
• Caddy: Einfach zu konfigurierender Reverse Proxy mit automatischem TLS

Was ist ein API Gateway?

Ein API Gateway ist eine spezialisierte Form des Reverse Proxy, die zusätzliche API-spezifische Funktionen bietet. Es sitzt am Eingang einer API-Infrastruktur und verwaltet, schützt und orchestriert den gesamten API-Verkehr.

Während ein Reverse Proxy auf HTTP-Ebene operiert (Pfade, Hostnamen, Headers), operiert ein API Gateway auf API-Ebene (Endpoints, API-Keys, OAuth-Tokens, Quotas, API-Versionen).

Kernfunktionen eines API Gateway (über Reverse Proxy hinaus)

• Authentifizierung & Autorisierung: OAuth 2.0, JWT-Validierung, API-Key-Prüfung an jedem Endpunkt
• API-spezifisches Rate Limiting: Quotas pro API-Key, pro Nutzer, pro Endpunkt — nicht nur pro IP
• Request/Response Transformation: Payloads umwandeln, Header hinzufügen, Versionen mappen
• API-Versionierung: /v1/users und /v2/users auf unterschiedliche Backends oder Versionen routen
• Request Aggregation: Mehrere Backend-Calls in einer Client-Anfrage zusammenfassen (API Composition)
• Protocol Translation: REST zu gRPC, SOAP zu REST, WebSocket zu HTTP
• API Analytics & Monitoring: Detaillierte Metriken pro Endpunkt, pro Consumer, pro API
• Developer Portal Integration: API-Dokumentation, Self-Service-Registrierung, Key-Management
• Circuit Breaker: Bei Backend-Ausfall automatisch Fehlerantworten statt Timeout-Warten
• Mocking: Endpunkte mocken für Entwicklung und Tests

Bekannte API Gateway Lösungen

• Kong: Open-Source API Gateway mit Plugin-System, basiert auf Nginx/OpenResty
• AWS API Gateway: Cloud-basiert, tief integriert in AWS-Ökosystem
• Apigee: Google Cloud API Management, Enterprise-Fokus
• Tyk: Open-Source, leichtgewichtig, Go-basiert
• KrakenD: High-Performance API Gateway mit Aggregation-Fokus
• Azure API Management: Microsoft Cloud-Lösung mit Developer Portal

Der wesentliche Unterschied

Die Unterscheidung lässt sich auf eine Formel bringen:

Reverse Proxy = Infrastruktur-Layer (HTTP, TCP, Routing, Load Balancing) API Gateway = API-Layer (Endpoints, Auth, Quotas, Transformation, Analytics)

Ein Reverse Proxy fragt: Welcher Server soll diese Anfrage bekommen? Ein API Gateway fragt: Ist dieser Client autorisiert, diesen Endpunkt aufzurufen, und wie viel darf er heute noch?

Vergleichstabelle

Wer nutzt was?

• Reverse Proxy: Sysadmins, DevOps-Engineers, die Traffic verteilen und TLS zentralisieren wollen
• API Gateway: API-Teams, Platform-Teams, die APIs verwalten, absichern und monetarisieren wollen

Warum ist das Thema in der Informatik und für Prüfungen wichtig?

In Architektur-Prüfungen und Zertifizierungen (AWS Solutions Architect, Azure API Management) wird regelmäßig nach dem Unterschied gefragt. In der Praxis führt Unwissenheit zu Architekturfehlern: Authentifizierungslogik wird in Reverse Proxies gepackt (wo sie nicht hingehört), oder API Gateways werden als reine Load Balancer missbraucht (Verschwendung von Funktionalität). Die korrekte Zuordnung von Verantwortlichkeiten ist ein Zeichen architektonischer Reife.

Warum ist das Thema in der Praxis wichtig?

Szenario 1: Microservices-Architektur

In einer Microservices-Architektur mit 20 Services braucht man beides: Den Reverse Proxy (z.B. Nginx/Envoy) für Load Balancing und TLS innerhalb des Clusters, und das API Gateway (z.B. Kong) als öffentlichen Eingang für externe Clients mit Auth, Quotas und Versionierung.

Szenario 2: Monolith mit API

Ein einzelner Backend-Server mit einer REST API braucht oft nur einen Reverse Proxy (Nginx) für TLS und Caching. Ein API Gateway wäre Over-Engineering.

Szenario 3: Multi-Client-Plattform

Eine Plattform mit Web-App, Mobile-App und B2B-API-Clients braucht ein API Gateway, denn jeder Client-Typ hat unterschiedliche Auth-Methoden, Quotas und benötigte Felder. Der Reverse Proxy reicht hier nicht aus.

Praxisbeispiel: Nginx als Reverse Proxy vs. Kong als API Gateway

Dieses Beispiel zeigt die gleiche Anforderung — einen /users Endpunkt absichern — einmal mit Nginx als Reverse Proxy und einmal mit Kong als API Gateway. Der Vergleich macht den Unterschied in Abstraktionsebene und Funktionalität deutlich.

Nginx als Reverse Proxy

# nginx.conf — Reverse Proxy Konfiguration
# Leitet Anfragen an Backend-Server weiter, mit TLS und Rate Limiting

upstream backend {
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    # Load Balancing: Round-Robin (Default)
    # Least-Connections: least_conn;
    # IP-Hash (Session-Stickiness): ip_hash;
}

# Rate Limiting Zone: 10 Requests pro Sekunde pro IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    listen 443 ssl;
    server_name api.example.com;

    # TLS Termination
    ssl_certificate /etc/ssl/certs/api.crt;
    ssl_certificate_key /etc/ssl/private/api.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    # /users -> Backend
    location /users {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # /orders -> anderer Backend-Server
    location /orders {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://10.0.0.3:3001;
        proxy_set_header Host $host;
    }

    # Health Check Endpoint
    location /health {
        return 200 "OK";
        add_header Content-Type text/plain;
    }
}

Kong als API Gateway

# kong.yml — Deklarative Konfiguration
# Definiert Services, Routes und Plugins (Auth, Rate Limiting, Analytics)

services:
  - name: user-service
    url: http://10.0.0.1:3000
    routes:
      - name: users-route
        paths:
          - /users
        methods:
          - GET
          - POST
          - PUT
          - DELETE
        # API-Versionierung über Header
        strip_path: false

  - name: order-service
    url: http://10.0.0.3:3001
    routes:
      - name: orders-route
        paths:
          - /orders
        methods:
          - GET
          - POST

plugins:
  # JWT Authentifizierung für alle Routes
  - name: jwt
    config:
      secret_is_base64: false
      run_on_preflight: true

  # Rate Limiting pro Consumer (nicht nur pro IP)
  - name: rate-limiting
    config:
      minute: 100
      hour: 1000
      policy: redis
      redis_host: redis.internal
      limit_by: consumer
      fault_tolerant: true

  # CORS Konfiguration
  - name: cors
    config:
      origins:
        - https://app.example.com
      methods:
        - GET
        - POST
        - PUT
        - DELETE
      headers:
        - Authorization
        - Content-Type
      credentials: true

  # Prometheus Metriken für API Analytics
  - name: prometheus
    config:
      per_consumer: true

consumers:
  - username: mobile-app
    jwt_secrets:
      - key: mobile-app-key
        secret: mobile-app-secret-2026
  - username: web-app
    jwt_secrets:
      - key: web-app-key
        secret: web-app-secret-2026

Der Unterschied ist erkennbar: Nginx konfiguriert HTTP-Routing und IP-basiertes Rate Limiting. Kong konfiguriert API-Routing mit JWT-Auth, Consumer-basiertem Rate Limiting, CORS und Metriken — alles deklarativ, pro API-Endpunkt.

Detaillierte Informationen

Kann ein API Gateway einen Reverse Proxy ersetzen?

Ja und nein. Ein API Gateway wie Kong basiert oft selbst auf einem Reverse Proxy (Kong nutzt Nginx/OpenResty unter der Haube). Es bietet alle Reverse-Proxy-Funktionen plus API-Funktionen. In vielen Architekturen ersetzt das API Gateway den Reverse Proxy für externen Traffic. Intern — zwischen Microservices — bleibt oft ein separater Reverse Proxy oder Service Mesh (Envoy, Linkerd) aktiv.

Wann reicht ein Reverse Proxy?

• Einzelne API oder Monolith
• Wenige Endpunkte, keine API-Versionierung
• Authentifizierung im Backend selbst (keine zentrale Auth nötig)
• Keine unterschiedlichen Quotas pro Client
• Kleines Team, begrenzte Infrastruktur

Wann brauchst Du ein API Gateway?

• Mehrere APIs oder Microservices hinter einem Eingang
• Zentrale Authentifizierung (OAuth, JWT) für alle APIs
• Unterschiedliche Quotas und Rate Limits pro Client/API
• API-Versionierung und -Migration
• Request Aggregation (ein Client-Call -> mehrere Backend-Calls)
• API-Analytics und Monetarisierung
• Developer Portal für Self-Service

Reverse Proxy vs. Load Balancer vs. API Gateway

Diese drei Begriffe werden oft vermischt:

• Load Balancer: Verteilt Traffic auf mehrere Server (Layer 4, TCP/UDP). Fokus: Verfügbarkeit. Beispiele: HAProxy, AWS ALB.
• Reverse Proxy: Leitet HTTP-Anfragen weiter, TLS, Caching (Layer 7). Fokus: Infrastruktur. Beispiele: Nginx, Caddy.
• API Gateway: Reverse Proxy + API-Management-Funktionen. Fokus: API-Governance. Beispiele: Kong, AWS API Gateway.

Ein Load Balancer kann Teil eines Reverse Proxy sein. Ein Reverse Proxy kann Teil eines API Gateways sein. Die Abstraktionsebene steigt von LB über RP zu AG.

Service Mesh vs. API Gateway

Ein Service Mesh (Istio, Linkerd) manages die Kommunikation zwischen Microservices (intern), während ein API Gateway den externen Verkehr verwaltet. In modernen Architekturen existieren beide: API Gateway außen, Service Mesh innen. Envoy kann beide Rollen einnehmen.

FAQ: API Gateway vs. Reverse Proxy

Weiter im API Lernpfad

Der nächste Artikel behandelt API Gateway Sicherheit — wie Du Authentifizierung, Rate Limiting und Bedrohungsschutz am API Gateway zentral konfigurierst.

Quellen und weitere Ressourcen

1. https://nginx.org/en/docs/
2. https://docs.konghq.com/
3. https://learn.microsoft.com/en-us/azure/api-management/
4. https://docs.aws.amazon.com/apigateway/
5. https://www.martinfowler.com/articles/richardson-maturity-model.html

Buchempfehlungen zur API-Entwicklung

API-Entwicklung

Bücher über API-Design, REST, GraphQL, OpenAPI und API-Architektur

REST und HTTP: Entwicklung und Integration nach REST-Prinzipien von Stefan Tilkov

Bei Amazon ansehen

Affiliate-Link: Bei einem Kauf erhalten wir möglicherweise eine Provision.

API-Design: Praxishandbuch für Java- und Webservice-Entwickler

Bei Amazon ansehen

Affiliate-Link: Bei einem Kauf erhalten wir möglicherweise eine Provision.

Microservices: Grundlagen flexibler Softwarearchitekturen von Eberhard Wolff

Bei Amazon ansehen

Affiliate-Link: Bei einem Kauf erhalten wir möglicherweise eine Provision.

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert