API Gateway für PHP-Dienste: Microservices einfach vereinen

Einleitung: Warum dein PHP-Projekt ein API Gateway braucht

Stell dir vor, du entwickelst eine moderne Webanwendung. Du hast einen User-Service in Laravel, einen Order-Service in Symfony, einen Payment-Service in reinem PHP und dazu externe Integrationen mit einem CRM und einem Telegram-Bot. Clients (Mobile App, SPA in React und eine alte, aber bewährte jQuery-Website) klopfen an verschiedenen Endpunkten an, verlieren den Überblick über Tokens, und du frickelst jede Woche an CORS-Einstellungen herum.

Kommt dir bekannt vor? Falls ja, brauchst du ein API Gateway – einen zentralen Einstiegspunkt für all deine Dienste. Es ist nicht nur ein einfacher Proxy, sondern ein echter Dispatcher, der sich um Routing, Authentifizierung, Caching und Datenaggregation kümmert.

In diesem Artikel zeigen wir dir, wie du ein einfaches, aber funktionsfähiges API Gateway in PHP schreibst, das du auf jedem Hosting bereitstellen kannst. Keine Zauberei, nur sauberer Code und Best Practices für eine Microservices-Architektur in PHP.

Was ist ein API Gateway und warum braucht ein PHP-Entwickler es?

Ein API Gateway (API-Gateway) ist ein Server, der alle eingehenden Client-Anfragen entgegennimmt und an die entsprechenden Microservices weiterleitet. Der Client kennt die interne Struktur nicht: Er sendet einfach eine Anfrage an /api/users, und das Gateway entscheidet selbst, wohin die Anfrage weitergeleitet wird.

Die Hauptaufgaben eines Gateways:

\n
• Routing – Weiterleitung von Anfragen an verschiedene Dienste basierend auf URL oder Headern.
\n
• Authentifizierung und Autorisierung – Prüfung von JWT-Tokens, API-Keys, Zugriffsbeschränkungen.
\n
• Aggregation – Zusammenführen von Daten aus mehreren Diensten in einer einzigen Antwort (z. B. Benutzerprofil + seine letzten Bestellungen).
\n
• Caching – Reduzierung der Backend-Last durch Zwischenspeicherung häufig abgerufener Daten.
\n
• Rate Limiting – Schutz vor DDoS und Überlastung der Dienste.
\n
• Antworttransformation – Vereinheitlichung der Datenformate für verschiedene Clients.
\n

Die Vorteile liegen auf der Hand: Vereinfachung der Client-Seite, zentrales Sicherheitsmanagement und die Möglichkeit, das Backend zu ändern, ohne die Clients zu informieren. Ein Nachteil ist der zusätzliche Single Point of Failure, aber das lässt sich durch Replikation des Gateways lösen.

Entwurf eines einfachen API Gateways in PHP

Wir schreiben das Gateway in reinem PHP ohne Frameworks, damit du das Prinzip verstehst. Du kannst den Code aber problemlos an Laravel, Symfony oder Slim anpassen.

Unser Gateway wird:

\n
• Anfragen an /api/users/* entgegennehmen und an den Users-Service (Port 8081) weiterleiten
\n
• Anfragen an /api/orders/* entgegennehmen und an den Orders-Service (Port 8082) weiterleiten
\n
• Vor der Weiterleitung den JWT-Token prüfen
\n
• GET-Anfragen für 60 Sekunden cachen
\n
• Daten aggregieren: /api/profile sammelt Informationen von Users und Orders
\n

Schritt 1: Routenkonfiguration

Wir erstellen eine Datei config.php, in der wir festlegen, welche URLs wohin führen:

<?php\n// config.php\nreturn [\n    'routes' => [\n        '/api/users' => [\n            'target' => 'http://127.0.0.1:8081',\n            'auth' => true,        // JWT erforderlich\n            'cache' => false       // nicht cachen (persönliche Daten)\n        ],\n        '/api/orders' => [\n            'target' => 'http://127.0.0.1:8082',\n            'auth' => true,\n            'cache' => 60          // 60 Sekunden cachen\n        ],\n        '/api/public' => [\n            'target' => 'http://127.0.0.1:8083',\n            'auth' => false,\n            'cache' => 120\n        ],\n        '/api/profile' => [        // aggregierter Endpunkt\n            'aggregate' => true,\n            'auth' => true,\n            'services' => [\n                'user' => 'http://127.0.0.1:8081/api/user',\n                'orders' => 'http://127.0.0.1:8082/api/order'