La finalité première d’une API Web est d’exposer des données dans le but d’être consommées, voire modifiées. Assez rapidement se pose donc la question de la sécurisation des accès à ces données. Mais d’autres aspects peuvent rapidement rejoindre ce premier, comme la gestion de la performance de l’API ou encore le respect de quotas d’accès.
Lorsqu’il s’agit d’une seule API, l’approche la plus directe pour traiter ces besoins secondaires mais néanmoins importants sera intuitivement d’ajouter ces responsabilités à l’API elle même. Bon nombre de solutions existent pour cela. La sécurité pourra trouver des réponses plus ou moins sophistiquées, du simple htaccess protégeant l’accès aux ressources à l’utilisation d’une librairie dédiée à la sécurité comme Spring Security ou Apache Shiro si les développements sont réalisés en Java, Passport avec NodeJS, etc. Une fois l’identité de l’appelant connue, la gestion des quotas n’est qu’une affaire d’accès en lecture/écriture à un compteur. Tout comme la gestion du cache, qui peut aussi trouver des réponses dans des librairies dédiées ou directement supporté par celle permettant la réalisation de l’API Web (Spring offre par exemple l’abstraction qui permet d’ajouter un cache applicatif de façon simple, Jersey, RESTLet, … qui proposeront une gestion des règles du cache HTTP).
Créer une API Web peut maintenant se faire simplement si bien qu’il est possible de voir leur nombre au sein d’un système d’information croître de façon importante. Alors, lorsque le nombre d’API commence à devenir important, il devient plus évident de considérer ces besoins comme des besoins transversaux. Et par conséquent, il n’est pas interdit de penser que ceux-ci puissent être traités en dehors des API.
Mais sous quelle forme cela pourrait se traduire ? Intuitivement, sous la forme d’un reverse proxy apte à servir tous ces besoins, et potentiellement d’autres aussi… Une telle brique portera le nom de passerelle pour API ou API Gateway.
Citons quelques fonctionnalités dont la gestion dans une telle brique du SI peut être très intéressante :
- La sécurité (authentification, potentiellement autorisation)
- La gestion de quotas d’accès et de throttling
- Le cache (déclarations et proxy cache)
- La composition/transformation des API
- Le routage (avec éventuellement transformation) vers les API “internes”
- La surveillance de l’état de santé des API (surveillance des performances, des erreurs, …)
- La gestion de versions des API (avec possible négociation de version automatique)
Quels avantages une telle approche pourrait avoir ?
- Le premier et le plus évident : mutualiser la logique en un seul point
- Rendre le code source des API plus simple puisque dépourvu des responsabilités déportées
- Offrir une vue centrale et unique des API et donc être plus apte à permettre une politique homogène
Quels inconvénients maintenant ?
- SPoF possible ou, dans le meilleur des pires cas :), un goulet d’étranglement
- Risque de complexité puisque concentration de toutes les règles de toutes les API en un point unique
- Adhérence à une solution avec migration vers une autre pas triviale
Est-ce une idée géniale à laquelle personne n’a encore pensé ? Non, loin de là, puisque nombre d’éditeurs disposent maintenant de solutions de ce type, plus ou moins richement dotées en fonctionnalités et de maturité variable.
Les produits commerciaux sont maintenant assez nombreux et ont commencé à entrer dans les cycles d’acquisition par les gros éditeurs (exemple : Intel acquiert Mashery en 2013, Computer Associates acquiert Layer 7 en 2013) ou des partenariats (SAP et Apigee en 2014). Tous ne sont pas égaux, certains sortent du lot et ont déjà acquis une notoriété visiblement légitime (Layer 7 par exemple qui compte dans ses effectifs des gurus des API Web).
Quid de l’OSS ?
Il existe quelques initiatives open source mais étrangement, ce marché est encore à prendre (avis aux amateurs). Citons quelques solutions :
- APIAxle (http://apiaxle.com/)
- Tyk (http://tyk.io/)
- apiGrove (http://apigrove.net/)
- WSO2 API Manager (http://wso2.com/products/api-manager/)
Toutes ces solutions n’ont pas la même traction dans le monde de l’open source et ne sont pas égales, loin s’en faut, en termes de fonctionnalités. De toutes et à ce jour, WSO2 API Manager est la plus riche et dispose d’un niveau de finition avancé. C’est une solution applicative pertinente pour permettre la mise en oeuvre d’un composant de type API Gateway open source, à un coût raisonnable (le coût étant celui du temps de montée en compétence et de mise en oeuvre). Pour autant, bien qu’avancée fonctionnellement, elle ne couvre pas forcément tout le spectre des fonctionnalités de ses concurrents payants.
Il reste toujours la possibilité de créer soit même ce composant lorsque les besoins attendus ne semblent pas justifier l’adoption d’une solution clef en main. Plusieurs solutions open source de reverse proxy peuvent être configurées pour apporter les fonctionnalités de base d’une API Gateway. Attention cependant au coût sur le long terme de telles solutions.
Considérez donc bien votre besoin pour identifier la stratégie adaptée : la prise en charge par l’API des aspects transverses peut être une solution rapide à mettre en place mais elle risque rapidement de perdre de son attractivité si votre porte feuille d’API s’étend. Assez rapidement, l’adoption d’une solution spécialisée va démontrer sa rentabilité. Qu’elle soit ensuite open source ou non, gratuite ou non, custom ou sur étagère, on-premise ou SaaS, … va dépendre de bien d’autres paramètres et ces choix doivent faire l’objet d’une étude.
