WSO2 API Manager

Ce que couvre le produit

WSO2 API Manager est une plateforme d’API management que l’on installe et que l’on exploite. La documentation 4.3.0 décrit un ensemble de composants pour concevoir des API, les publier, les exposer à des applications consommatrices et observer le trafic. Le produit traite des API REST, y compris à partir d’une définition OpenAPI, des API GraphQL, de l’exposition d’un service SOAP en REST, ainsi que des API de streaming : WebSocket, WebSub / WebHook, SSE et définitions AsyncAPI.

Le code du gestionnaire est publié en open source. Une souscription commerciale existe chez l’éditeur pour le support et certaines distributions. La description ci-dessous s’appuie sur la documentation WSO2 API Manager 4.3.0 et sur la page d’architecture.

Architecture typique

La documentation sépare trois plans. Le plan de gestion comprend l’API Publisher, le portail développeur, le catalogue de services et l’analytique. Le plan de données porte les appels : passerelle API, Micro Integrator et Streaming Integrator. Le plan de contrôle réunit le Key Manager, qui délivre et valide les jetons, et le Traffic Manager, qui porte les décisions de quota.

En déploiement resserré, ces rôles tiennent sur un seul runtime. Dès que le trafic ou les exigences d’isolation augmentent, la documentation décrit un déploiement distribué : la passerelle peut être configurée à part, le Key Manager peut être WSO2 Identity Server ou un gestionnaire de clés tiers, et les bases par défaut peuvent être remplacées par MySQL, PostgreSQL, SQL Server, Oracle ou DB2. La passerelle est le composant qui se dimensionne avec le volume d’appels. Le Publisher et le portail se dimensionnent avec le nombre d’utilisateurs qui administrent ou découvrent les API.

Deux passerelles, production et bac à sable, peuvent rester séparées. Les révisions d’API permettent de préparer une configuration puis de la déployer, plutôt que de modifier directement l’état servi. Les politiques de passerelle couvrent la médiation, la mise en cache de réponse, la protection contre certaines charges abusives et le passage d’attributs de l’utilisateur final vers le backend.

Points forts et limites

Le produit réunit, dans une même distribution, la publication, le portail, la délivrance de clés et la passerelle. Une équipe qui doit héberger la plateforme dans son propre réseau y trouve un cycle de vie explicite : conception, sécurité de l’endpoint, versions, dépréciation, produits d’API qui regroupent plusieurs ressources pour un consommateur. L’import OpenAPI réduit l’écart entre le contrat et le proxy publié.

La contrepartie est l’exploitation. Il faut tenir les bases, les certificats, les keystores, les montées de version et la cohérence entre plan de gestion et passerelles. Un déploiement distribué multiplie les processus à superviser. L’analytique, selon l’option retenue dans la documentation (offre cloud de l’éditeur ou pile sur site), ajoute encore un composant. Le produit est large : une équipe qui n’a besoin que d’un proxy HTTP devant deux services en tire peu de bénéfice tant que le portail, les quotas et le cycle de vie ne sont pas des besoins réels.

Les politiques de médiation sont puissantes et, pour cette raison, faciles à rendre opaques. Une transformation de payload ou un routage dynamique codé dans la passerelle devient une dette dès que le service backend évolue. La limite saine est de garder dans la passerelle l’authentification, les quotas, la journalisation et les contrôles de sécurité, et de laisser les règles métier dans les services.

Quand le retenir

WSO2 API Manager est un candidat sérieux lorsque la passerelle doit rester dans un réseau que l’organisation contrôle, sur machines virtuelles, conteneurs ou Kubernetes, et lorsque le portail développeur et le gestionnaire de clés font partie du besoin initial. Il l’est aussi lorsque les API à exposer mêlent REST, SOAP existant et flux asynchrones déjà couverts par le produit.

Il est moins adapté lorsque l’équipe veut un service entièrement opéré par un fournisseur cloud, facturé à l’appel, sans maintenir de runtime. Il l’est également lorsque le seul besoin est un ingress HTTP avec quelques plugins : d’autres passerelles, plus étroites, suffisent. Le choix se compare alors avec Kong, Gravitee et les offres managées, dans le comparatif.

Migration et intégration

Une reprise part d’un inventaire : contrats OpenAPI ou WSDL, méthodes d’authentification réellement utilisées, quotas, adresses de backend, certificats mutuels et consommateurs déjà abonnés. L’import d’une définition crée le squelette du proxy. Il ne transporte pas les règles implicites qui vivaient dans un autre produit, ni les comptes du portail, ni l’historique d’analytique.

Côté identité, il faut décider si le Key Manager du produit émet les jetons ou s’il délègue à un fournisseur déjà en place. Les deux options sont documentées. Les changer après coup oblige les applications consommatrices à reprendre leurs secrets et leurs URL de jeton. Les backends se raccordent en HTTP, avec sécurisation Basic, Digest ou OAuth 2.0 selon les cas décrits dans la documentation, ou en TLS mutuel entre la passerelle et le service.

Les environnements gagnent à être séparés tôt : au minimum un bac à sable et une production, avec des bases distinctes. Un annuaire d’API copié d’un environnement à l’autre sans revue des endpoints est une source classique d’appels de production vers un service de test.

Ce que Technocify peut prendre en charge

L’intervention couvre l’audit de l’existant, la conception du découpage entre plans, la mise en œuvre et le run. L’audit liste les API, les consommateurs, les secrets et les écarts entre la documentation annoncée et le trafic réel. La conception fixe ce qui relève de la passerelle et ce qui reste dans les services, le mode de déploiement et la stratégie de clés. La mise en œuvre installe le runtime, raccorde les premiers contrats et vérifie un parcours complet : obtention d’un jeton, appel, quota, trace. Le run porte les mises à jour, la supervision et les changements de version d’API.

Les équipes Technocify s’appuient sur une pratique de l’intégration et des API depuis 2009. Nos consultants sont certifiés WSO2 API Manager Practitioner V4 (2023), WSO2 API Manager Developer V3 (2021), MuleSoft Developer V4 (2022), Workato Automation Pro I, II, III (2025, valides jusqu’en 2027) et ITIL V4 (2020). Le détail figure sur la page À propos.

Le déploiement sur Kubernetes est traité à part dans l’article WSO2 API Manager sur Kubernetes. Le périmètre d’ingénierie associé est décrit dans les pages plateformes API et cloud, interopérabilité et DevSecOps.