Dans ce premier article sur la thématique de l’API Management, je vous propose d’identifier en quoi ce type de solution peut apporter de la valeur pour l’ensemble des acteurs de la chaîne de développement logiciel.

J’ai mal à mon API, c’est grave docteur ?

En tant que développeur d’applications clientes (que ce soit des apps mobiles, du Web ou des clients WPF/WinForms), nous sommes amenés à exploiter des API sous forme de Web Services.

Et combien de fois n’avons nous pas pesté contre l’absence de documentation à jour (ou pour les plus chanceux sur la simple incohérence des formats de documentation), la multiplicité des points d’entrée (pour l’API qui liste les données de référence géographiques, c’est sur le serveur A, mais pour passer une commande il faut interroger le serveur B, et pour authentifier l’utilisateur c’est où déjà ?).

En tant que développeur de plateformes de services, exploite-t-on bien notre temps en le passant à gérer des problématiques transverses comme le contrôle d’accès, la gestion des statistiques d’usage, le cycle de vie des différentes versions de nos services ?

Quelle que soit notre casquette, on ressent le besoin d’une brique additionnelle dans la relation client de Web Service / serveur de Web Service, qui industrialiserait nos relations , et nous permettrait d’être efficaces dans notre travail et dans l’exploitation de nos plateformes.

C’est ainsi que s’est développé sur le marché une offre de solutions d’API Management, dont les plus connues sont Apigee (racheté par Google), IBM API Management, Mulesoft for Anypoint Platform for APIs (joli branding).

Les apports d’une solution d’API Management

Que l’on développe une API pour les besoins internes d’une entreprise ou pour des clients extérieurs, les ambitions de base d’une solution d’API Management sont de rendre ces API aisément partageables, plus sécurisées et plus gérables du point de vue de la gouvernance de la DSI.

Pour cela, tout un éventail de services est fourni par la plupart des solutions du marché.

Nous allons les passer en revue… mais avant cela, une précision s’impose pour la compréhension du positionnement de ces solutions : une solution d’API management est une brique supplémentaire à valeur ajoutée qu’on introduit dans le SI pour servir d’intermédiaire entre les consommateurs et les Web Services. Gardons bien en tête que ce n’est pas la solution d’API Management qui héberge les Web Services, elle ne remplace pas nos chers serveurs IIS/ASP.NET, et on peut la voir comme un proxy « de luxe », si vous me permettez cette image.

Passons donc à une revue de ces services à valeur ajoutée…

Packaging et publications

Avec une solution d’API Management, il est possible de regrouper des API en packages qui sont ensuite publiés pour être consommés par les développeurs internes ou les acteurs extérieurs (clients, partenaires…).

Ces packages peuvent correspondre

• à différents blocs fonctionnels, pour permettre d’isoler les Web Services en unités cohérentes,
• à différents niveaux d’abonnements pour un service que j’offre à l’extérieur, pour permettre d’offrir une profondeur de service ou un SLA différent selon ce niveau d’abonnement.

Ces packages peuvent donner lieu à une facturation, dont la solution d’API Management va permettre d’établir la consommation pour chaque client.

La solution d’API Management joue donc un rôle très utile pour contingenter et suivre la consommation des services que j’expose, sans avoir à écrire une seule ligne de code.

Portail self-service

La plupart des solutions permettent au consommateur de l’API de s’enregistrer et d’obtenir des clés d’usages (associés aux packages précités) entièrement en ligne; cela est un facteur de facilitation de l’accès à l’API

Pour les cas d’usage où cela a un sens (API publique), c’est un gain de temps énorme pour les équipes d’exploitation qui n’ont pas à traiter manuellement les demandes d’accès.

En entreprise, l’utilité est moins flagrante car les processus de validation des accès aux API nécessite des interventions humaines, en général de la cellule urbanisation.

Documentation, exemples, console

Le portail d’API Management fournit une documentation cohérente pour l’ensemble des API qui y sont déclarées, en se reposant sur des standards (Swagger, etc).

Il fournit aussi des exemples de code pour appeler ces API, potentiellement dans de multiples langages (C#, Java, PHP).

Enfin, il fournit souvent une console de test de l’API, qui permet de découvrir et de jouer avec l’API sans avoir à implémenter une application cliente.

Tout cela permet aux développeurs de découvrir avec une grande facilité le fonctionnement des API que l’on offre, ce qui réduit les questions qui peuvent être adressées au support technique et ce qui nous permet donc de passer du temps sur des choses plus intéressantes que d’expliquer pour la 10ème fois comment attaquer telle méthode de tel Web Service !

Une façade pour des Web Services existants

La solution d’API Management va permettre également de fournir une façade pour des Web Services existants.

On peut ainsi regrouper sous une même API des Web Services fournis par différents serveurs applicatifs, et uniformiser le nommage du chemin d’appel vers les Web Services.

On peut aussi facilement changer les implémentations backend appelées par les requêtes reçues par l’API Management, et cela de manière transparentes pour les clients, ce qui est utile pour gérer le cycle de vie des Web Services.

Enrichissement de la capacité des API

La brique d’API Management peut ajouter des mécanismes de cache en lieu et place des Web Services backend, afin d’améliorer la qualité de service globale.

Protection des API

Les solutions d’API Management permettent de sécuriser les accès aux API, en s’assurant que les appelants sont bien autorisés à le faire (authentification, token OAuth, clés d’API); on peut les relier à des mécanismes d’IAM (Identity and Access Management) pour une plateforme totalement intégrée.

On peut aussi s’assurer que les utilisateurs n’ont recours qu’à un volume de transactions raisonnable en imposant des règles de plafonnement des requêtes. Cela apporte une protection contre certaines attaques de déni de service, et permet de s’assurer que les ressources d’hébergement sont taillées pour la demande.

Statistiques et monitoring des API

Le dernier service à valeur ajoutée est un besoin transverse que l’on est souvent amené à développer dans nos implémentations de Web Services, et que la brique d’API Management va nous apporter : la collecte de statistiques d’usage, et le monitoring de l’état de santé de l’API.

Ces solutions nous permettent de collecter les temps moyens de traitement des appels, et aussi de mesurer l’évolution de la consommation de nos Web Services (utile pour déclencher les décommissionnements de Web Services obsolètes !)

 

API Management vs Enterprise Service Bus

La première fois que l’on m’a parlé d’API Management, ma réaction fut assez vite de dire : mais pourquoi introduire cette nouvelle brique alors qu’on a déjà un bus de services (ESB) dans l’infrastructure ?

On peut en effet penser de prime abord que dont on peut penser qu’il y a recouvrement dans les fonctionnalités, et la confusion est renforcée par la présence d’un produit d’API Management parmi les acteurs qu’on associe traditionnellement à l’ESB (MuleSoft, Tibco).

En fait, le positionnement de ces 2 types de solution est assez différent.

La raison d’être d’un ESB est d’orchestrer les flux de l’entreprise : réception des requêtes, transformation de celles-ci si nécessaire, appel du service en synchrone ou en asynchrone (queues de message), mécanismes de rejeu, transformation des réponses avant retour à l’appelant.

L’API Management ne vise pas à répondre à ces problématiques : pas de capacité de transformer les données, pas de fonctionnement intrinsèquement asynchrone.

Au final, le seul point commun serait la fonctionnalité de catalogue de services, mais l’API Management va être plus orienté vers le développeur pour lui offrir un portail facile d’accès pour découvrir les services, alors que l’ESB aura un rôle beaucoup plus technique.

Il y a donc de la place pour tout le monde, et cela explique que les éditeurs du marché de l’ESB, entre autres, ajoutent l’API Management à leur offre de solutions.

En synthèse

On l’a vu, l’API Management vise à simplifier la vie des développeurs en accélérant la prise en main des différentes API que peut offrir une entreprise.

Il offre également une brique centralisée pour que l’entreprise s’assure d’une offre de services cohérente, maîtrisable et évolutive.

Si l’intérêt est évident pour les entreprises dont la fourniture d’API à l’extérieur est le cœur de métier (l’exposition de cartographie par exemple), il est aussi présent pour un usage strictement interne, pour s’assurer de la bonne gouvernance dans une architecture orientée services sur laquelle se greffe les applicatifs métiers.

Dans un prochain article, on passera aux travaux pratiques en mettant en place une instance d’API Management depuis l’offre Azure API Management de Microsoft.