Pourquoi votre projet C# a-t-il besoin d'un API Gateway ?
\n\nImaginez que vous construisez une application web moderne en C#. Vous avez un service utilisateurs, un service commandes, un service paiements — et chacun d'eux vit sur son propre port, voire sur des serveurs différents. L'application cliente (frontend ou application mobile) doit connaître toutes ces adresses, ces formats de données, ces protocoles d'authentification. Un cauchemar, n'est-ce pas ?
\n\nC'est là qu'intervient l'API Gateway pour les services C# — un point d'entrée unique qui prend en charge tout le "travail sale" : routage, agrégation des réponses, vérification des tokens, mise en cache et équilibrage de charge. Dans cet article, nous allons voir comment implémenter une passerelle API .NET en pratique, en utilisant des outils modernes comme Ocelot C# et YARP .NET.
\n\nQu'est-ce qu'un API Gateway et pourquoi est-il nécessaire pour les microservices ?
\n\nUn API Gateway est une couche intermédiaire entre les clients et vos services backend. Il fonctionne comme un "répartiteur" : il reçoit les requêtes HTTP entrantes, les analyse et les redirige vers les microservices C# appropriés. La passerelle peut également effectuer des tâches supplémentaires :
\n\n- \n
- Routage des requêtes — diriger les requêtes vers différents services en fonction de l'URL, des en-têtes ou des paramètres. \n
- Agrégation de données — collecter les réponses de plusieurs services et renvoyer un JSON unique au client. \n
- Authentification API Gateway — vérifier les tokens JWT ou les clés API avant que la requête n'atteigne le service. \n
- Équilibrage de charge — répartir les requêtes entre les instances d'un même service. \n
- Mise en cache — stocker temporairement les réponses pour les données fréquemment demandées. \n
- Rate Limiting — limiter le nombre de requêtes d'un même client. \n
Sans passerelle API .NET, chaque client doit connaître l'architecture de l'ensemble du système. Avec elle, le client communique avec un seul point de terminaison, et tout le reste se passe "sous le capot".
\n\nDeux outils principaux pour l'API Gateway en C#
\n\nDans l'écosystème .NET, il existe deux solutions puissantes qui méritent votre attention :
\n\nOcelot C#
\nSans doute le API Gateway pour les services C# le plus populaire. Ocelot est une bibliothèque open source qui ajoute des fonctions de passerelle à toute application ASP.NET Core. Il prend en charge :
\n- \n
- Le routage basé sur une configuration JSON \n
- L'agrégation des réponses \n
- L'authentification et l'autorisation \n
- Le Rate limiting \n
- L'équilibrage de charge (RoundRobin, LeastConnection) \n
- Les WebSockets \n
YARP .NET (Yet Another Reverse Proxy)
\nUn projet de Microsoft, positionné comme un proxy inverse haute performance. YARP est plus flexible et plus performant, mais nécessite plus de configuration manuelle. Il est parfait si vous avez besoin d'un contrôle total sur chaque requête.
\n\nDans cet article, nous nous concentrerons sur Ocelot — il est plus simple pour démarrer et couvre 90 % des tâches typiques.
\n\nCréation d'un API Gateway en C# avec Ocelot : guide étape par étape
\n\nÉcrivons du code concret. Nous allons créer une passerelle API .NET qui routera les requêtes vers deux microservices : UserService (port 5001) et OrderService (port 5002).
Étape 1 : Création du projet
\nOuvrez un terminal et exécutez :
\ndotnet new webapi -n ApiGatewayDemo\ncd ApiGatewayDemo\n\nInstallez le package Ocelot :
\ndotnet add package Ocelot\n\nÉtape 2 : Configuration du routage
\nCréez un fichier ocelot.json à la racine du projet. Nous y décrirons les règles de routage :
{\n "Routes": [\n {\n "DownstreamPathTemplate": "/api/users/{everything}",\n "DownstreamScheme": "http",\n "DownstreamHostAndPorts": [\n