Introduction : pourquoi votre projet PHP a besoin d'un API Gateway
\n\nImaginez que vous construisez une application web moderne. Vous avez un service utilisateurs sur Laravel, un service commandes sur Symfony, un service paiements en PHP pur, sans oublier des intégrations externes avec un CRM et un bot Telegram. Les clients (application mobile, SPA React et un bon vieux site jQuery) frappent à différentes portes, se mélangent les pinceaux avec les tokens, et vous passez vos semaines à corriger le CORS.
\n\nÇa vous parle ? Si oui, il vous faut un API Gateway — un point d'entrée unique pour tous vos services. Ce n'est pas qu'un simple proxy, c'est un véritable chef d'orchestre qui gère le routage, l'authentification, la mise en cache et l'agrégation des données.
\n\nDans cet article, nous allons voir comment écrire un API Gateway en PHP simple mais fonctionnel, déployable sur n'importe quel hébergement. Pas de magie, juste du code propre et les meilleures pratiques pour une architecture microservices en PHP.
\n\nQu'est-ce qu'un API Gateway et pourquoi en avez-vous besoin en PHP
\n\nUn API Gateway (passerelle API) est un serveur qui reçoit toutes les requêtes entrantes des clients et les redirige vers les microservices appropriés. Le client ignore tout de la structure interne : il envoie simplement une requête à /api/users, et le Gateway décide où l'acheminer.
Les principales fonctions de la passerelle :
\n- \n
- Routage — rediriger les requêtes vers différents services en fonction de l'URL ou des en-têtes. \n
- Authentification et autorisation — vérifier les tokens JWT, les clés API, restreindre l'accès. \n
- Agrégation — combiner les données de plusieurs services en une seule réponse (ex : profil utilisateur + ses dernières commandes). \n
- Mise en cache — réduire la charge sur le backend en mettant en cache les données fréquemment demandées. \n
- Rate limiting — protection contre les attaques DDoS et la surcharge des services. \n
- Transformation des réponses — uniformiser les données pour différents clients. \n
Les avantages sont évidents : simplification du côté client, gestion centralisée de la sécurité, possibilité de modifier le backend sans prévenir les clients. L'inconvénient est un point de défaillance supplémentaire, mais cela se résout par la réplication du Gateway.
\n\nConcevoir un API Gateway simple en PHP
\n\nNous allons écrire un Gateway en PHP pur sans framework, pour que vous compreniez l'essentiel. Vous pourrez facilement l'adapter à Laravel, Symfony ou Slim.
\n\nNotre passerelle va :
\n- \n
- Recevoir les requêtes sur
/api/users/*et les rediriger vers le service Users (port 8081) \n - Recevoir les requêtes sur
/api/orders/*et les rediriger vers le service Orders (port 8082) \n - Vérifier le token JWT avant de laisser passer la requête \n
- Mettre en cache les requêtes GET pendant 60 secondes \n
- Agréger les données :
/api/profilerassemblera les informations de Users et Orders \n
Étape 1. Configuration des routes
\n\nCréons un fichier config.php qui décrit où mènent les différentes URL :
<?php\n// config.php\nreturn [\n 'routes' => [\n '/api/users' => [\n 'target' => 'http://127.0.0.1:8081',\n 'auth' => true, // JWT requis\n 'cache' => false // pas de cache (données personnelles)\n ],\n '/api/orders' => [\n 'target' => 'http://127.0.0.1:8082',\n 'auth' => true,\n 'cache' => 60 // cache 60 secondes\n ],\n '/api/public' => [\n 'target' => 'http://127.0.0.1:8083',\n 'auth' => false,\n 'cache' => 120\n ],\n '/api/profile' => [ // endpoint agrégé\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