API : comment les maitriser et en tirer de la valeur

C'est grâce à leur bonne gestion et à la maîtrise de leur cycle de vie que l'entreprise aura une connaissance accrue de ses ressources, pourra les partager avec son écosystème et en tirer de la valeur. Mais comment s'y prendre ?

Les API positionnées dans un système back-end permettent l'interfaçage à des sources de données ou des applications, génératrices de valeur pour les utilisateurs. La maîtrise de cet écosystème passe en premier lieu par une phase d'identification de ces ressources au sein de l'entreprise mais aussi de leurs utilisateurs :

• Quelles sont les ressources auxquelles les utilisateurs peuvent et souhaitent accéder ?
• Quelle est l'identité de chaque utilisateur (personne physique ou morale, compte applicatif.) et avec quels outils souhaite-t-il accéder aux ressources (application, portail web, client lourd, poste de travail, appareil mobile.) ?

C'est en regroupant les identifications utilisateurs/ressources dans un point central que l'on pourra organiser une politique de gestion de droits d'accès aux ressources, pour garantir la sécurité de l'ensemble. Il devient ainsi possible de définir des autorisations à certains utilisateurs, depuis certains types d'environnements et d'outils autorisés, selon une période temporelle définie si nécessaire, pour qu'ils puissent accéder à certains types de ressources, et pas d'autres.

Gestion centralisée de la sécurité

Bien qu'un nombre illimité de services puissent être mis à disposition au sein de la plateforme d'API, chacun susceptible de disposer d'une politique de sécurité différente, il n'en demeure pas moins qu'un seul point d'accès devra être mis à disposition et visible par les applications consommatrices de données.

Cela va permettre d'instaurer une politique de gouvernance commune et donc de proposer :

• Une authentification unifiée (de type OpenId, SamI.) pour pouvoir récupérer de manière homogène les rôles et droits des utilisateurs dans l'environnement de l'entreprise.
• Une gestion des droits d'accès basée sur une catégorisation des API back-end selon leur niveau de confidentialité (avec une nomenclature de type C1 à Cn) correspondant à un niveau d'accréditation nécessaire pour que les utilisateurs puissent y accéder. 

Au sein de ces droits d'accès, il va alors être possible de définir des capacités d'accès pour les utilisateurs et leurs applications selon des engagements de services (SLA) contractualisés selon des plans de type Gold, Silver, etc., établissant un niveau de consommation limité de la ressource recherchée.
Par exemple, dans le cadre de son plan Silver, un utilisateur aura le droit d'accéder à une certaine API 50 fois par jour, uniquement en semaine de 7h à 20h.

Si l'on a la possibilité de mettre en place ces plans de consommation, c'est grâce aux mesures d'appels des ressources qui sont mises à disposition au sein de la plateforme de gestion des droits d'accès aux API. Cette connaissance du niveau de sollicitation de la plateforme et des flux sortants est une brique essentielle de la maîtrise de ses ressources car elle permet de connaître le succès d'une API par rapport à une autre. C'est ainsi que l'on pourra ensuite envisager une politique de rémunération de l'accès à ces ressources.

Garantie de performance de la plateforme et santé des API

En plus de pouvoir quantifier le niveau d'utilisation de ses API, la plateforme de gestion va également fournir d'autres indicateurs qui vont permettre de connaître les latences induites par la plateforme elle-même mais aussi les latences du service exposant la ressource. Ces informations permettront d'identifier les API en difficulté et de localiser rapidement les goulots d'étranglement.

Si nécessaire, la plateforme sera alors en mesure de prioriser les appels de ressources ou encore d'utiliser un mode BackPressure consistant à limiter le débit en amont pour éviter la surcharge en aval. Ce qui permettra d'empêcher la saturation du service back-end, qui au-delà d'une certaine limite deviendrait totalement inaccessible. 

A cela, il est important d'ajouter des outils de supervision avec un déploiement de sondes afin de connaître l'état de son réseau et l'état de santé des API exposées. En fonction de leur niveau de disponibilité, des actions spécifiques pourront alors être mises en place pour prévenir le support et les clients applicatifs qu'une ressource back-end n'est plus disponible. Puis potentiellement transférer automatiquement les appels vers une autre ressource équivalente disponible au sein d'un cluster.

Gestion des versions : naissance, vie et mort des API

La gestion des versions des API est l'un des aspects les plus complexes dans un cadre de développement car l'objectif est de pouvoir en proposer plusieurs versions différentes tout en ayant le moins d'impact possible sur les utilisateurs et leurs applications utilisatrices. Parmi ces dernières, certaines ont la possibilité d'être mises à jour rapidement, mais d'autres ne peuvent pas forcément suivre le rythme très rapide du cycle de vie d'un service back-end.

Il est donc essentiel de mettre en place des périodes de recouvrement durant lesquelles plusieurs versions seront disponibles. Cela pourra être géré au niveau de l'API elle-même avec un développement du back-end, mais il est aussi possible d'instaurer une politique globale des versions dans la plateforme centrale de gestion du cycle de vie des API, pour une meilleure efficacité. Le chemin d'accès vers la version pourra être défini dans l'adresse URL ou l'entête HTTP d'appel exposé par la plateforme, qui pourra alors router la demande vers la bonne version d'API.

La plateforme centrale d'API Management aura enfin comme fonction de gérer la fin de vie d'une API en indiquant dans ses messages un état d'obsolescence, avec des informations sur l'arrêt d'utilisation à venir de cette API.

Documentation essentielle pour la connaissance et le partage

Toutes les informations sur la durée de vie, les versions et l'obsolescence des API doivent être regroupées dans une documentation centralisée et unifiée que l'on nomme Catalogue de Services. Quels que soient la variété des services back-end et les langages qu'ils utilisent, cette documentation doit être suffisamment claire, précise et homogène, pour permettre à chaque développeur de savoir comment utiliser les API et à leur fournisseur de communiquer efficacement sur les nouvelles versions et leurs améliorations.

L'objectif est de proposer une description des éléments formant le contrat de service et d'être agnostique quant aux langages utilisés.
Pour réussir cette démarche, des standards de communication doivent être utilisés afin de permettre une génération automatique du code client et donc une mise en place d'applications.
Deux principaux standards sont généralement utilisés : le WSDL (Web Service Description Language) pour le protocole SOAP, et l'OpenAPI (Swagger) pour l'architecture REST. Il en existe également d'autres comme RAML ou RESTful API Modeling Language.

La diffusion de cette documentation est indispensable lorsque l'on partage ses ressources avec son écosystème, à travers un portail dans lequel seront référencés les différents services et leur API. Ce point central permet également de gérer la communauté de développeurs, qu'ils soient fournisseurs ou consommateurs d'API, et de proposer des formations.

Valorisation et monétisation des API

La maîtrise de son écosystème d'API est la clé pour améliorer la connaissance sur leur utilisation et finalement de les valoriser. La mise en place d'outils de supervision permettent en effet d'obtenir une visibilité sur l'importance de certaines API par rapport à d'autres, à travers des tableaux de bord complets mettant en évidence leur utilisation : fréquence d'appels, caractéristiques des appelants, typologies d'appareils utilisés, localisation, typologies d'appel, etc. 

Autant d'informations pouvant être exploitées par les métiers, et qui valorisent donc les API. On pourra alors allouer plus ou moins de ressources physiques sur chacune d'entre elles, le besoin d'hébergement n'étant pas le même pour une API appelée 100 fois par jour par rapport à une autre sollicitée 1000 fois par heure.

L'ensemble de ces mesures valorisant les API va ouvrir la porte vers leur monétisation, à l'aide d'outils tiers. Cette économie des API ainsi créée va permettre de rétribuer le développeur d'une API ou bien de faciliter le co-financement d'une plateforme de gestion des API au sein de l'entreprise. En interne, l'entité qui contrôle la plateforme (a priori la DSI) gagne en effet la possibilité de refacturer aux départements métiers consommateurs d'API, selon leur niveau de sollicitation.

Créer et gérer un catalogue d'API permet donc à l'entreprise de garder le contrôle de ses données et services mais aussi de mettre en place un processus que l'on peut inscrire dans une vision plus large de gestion des ressources, à l'aide d'une plateforme d'entreprise associée à d'autres outils d'intégration complémentaires comme un iPaaS.

_{crédit photo © Rawpixel.com / Shutterstock.com}

Jérémie Devillard, Co-Fondateur et Directeur Technique - Moskitos.