Panorama des solutions d’API Management

Le marché des solutions de gestion des API est en voie de consolidation, si l’on considère les rachats significatifs qui ont eu lieu ces derniers mois: Intel a racheté Mashery, CA Technology s’est offert Layer7 et Axway a rajouté Vordel à son catalogue.

Outre ces mouvements d’acquisition, la couverture fonctionnelle de ces solutions tend à s'homogénéiser, à un point qu’on a pu parler de commoditization des solutions d’API management. Elles proposent en effet toutes les mêmes solutions qui ne sont que des briques «de base» pour piloter et gérer ses APIs. De fait, toutes les entreprises qui veulent faire un choix de solutions pour mieux gérer leurs APIs ont du mal à les distinguer tant les services qu’elles proposent et les messages véhiculés se ressemblent comme deux gouttes d’eau.

Le marché de l’API management est par ailleurs hétérogène car non saturé : preuve en est le dynamisme qu’apporte l’arrivée de nouveaux entrants qui n’a pas cessé depuis 2005. Pour donner un premier aperçu des acteurs en présence, on peut distinguer quatre tendances :

• La première tendance, les solutions complètes et intégrées d’API Management, parmi lesquelles: Layer7, Apigee, Mashery, Axway, 3Scale, SOA Software, WSO2, ApiSpark, etc.
• La deuxième tendance est celle des services centrés sur la publication et l’accès à des données brutes. C’est un peu le mouvement d’Open Data mais via des API: InfoChimps (racheté par CSC en 2013), OpenDataSoft ou WebServius.
• La troisième tendance est constituée par des services très ciblés destinés à aider les développeurs d’APIs. Cela peut être aider à produire la documentation de l’API (APiary.io), un catalogue pour trouver et publier ses APIs (Mashape).
• Enfin, parmi toutes les solutions pour aider au développement et à la gestion des API, il y a un grand absent, qui pourrait transformer profondément le marché s’il le souhaite: il s’agit bien évidement de Google.

Les solutions intégrées d’API Management

Les solutions, apparues autour de 2005, se sont d’abord distinguées par leurs portails, qui permettent aux développeurs tiers de découvrir les APIs proposées, d’accéder à la documentation, à des services sociaux autour des APIs et d’obtenir les APIs Key pour pouvoir commencer à utiliser les APIs proposées. À ces pure players se sont greffées des solutions orientées SOA Gouvernance qui existait bien avant, tels SOA Software et Layer7.

On a donc assisté, sur la dernière décennie, à une fusion des marchés de la SOA avec celui de l’API management. D’ailleurs le Gartner identifie le marché des Application Services Management comme étant la somme des offres de SOA Gouvernance et d’API management.

L’architecture fonctionnelle des solutions d’API Management

Ces solutions comprennent trois briques. Le portail développeur (découverte, self-service, community management, analyse & monitoring), la gestion des API (sécurisation, gestion des identités, gestion des volumes de trafic, facturation, cycle de vie) et l’API Proxy & gateway (gestion technique de la plateforme, transcodage et enrichissement des messages, optimisation des flux pour mobiles).

Architecture technique des solutions d’API Management

Kin Lane, un ancien rédacteur du site Programmable Web, a proposé une distinction entre les différentes solutions d’API Management concentrée sur leur composant Gateway.

On distingue ainsi trois types d’architecture: la première consiste à installer un module ou connecteur dans le système d’information qui va jouer le rôle d’une sonde active en communiquant avec une plateforme d’API Management en SaaS. C’est la manière dont procède la solution 3Scale, qui se trouve être la plus simple à mettre en œuvre mais qui suppose que non seulement l’API soit bien conçue mais aussi que l’on prenne en charge soi-même sa publication (3Scale peut s’utiliser avec Nginx pour ajouter un proxy Open Source à l’architecture).

La deuxième architecture technique, celle qui repose sur l'utilisation d’un Proxy propriétaire, prend en charge la publication de l’API et rajoute un certain nombre de services de management dans le transfert des messages.

L’utilisation d’un Proxy suppose toutefois que l’on a bien conçu son API car une solution basée sur un Proxy ne va pas nécessairement ouvrir les messages de l’API ; dit autrement une solution basée sur un Proxy n’ouvre pas les messages mais se contente de rajouter des services de management aux messages.

Parmi les offres d’API management basées sur un Proxy, on trouve Apigee et Mashery qui offrent toutefois des fonctionnalités de «médiation», c’est-à-dire de transcodage des messages permettant de transformer une API SOAP-XML en REST-JSON, sans pour autant trop en espérer.

Pour aller plus loin en termes de transformation et d’enrichissement de son API, il faut regarder du côté des Gateways.

Avec les solutions basées sur une Gateway, on a la possibilité de concevoir des APIs à partir de n’importe quel message interne: que ce soit des services SOAP internes ou des flux de messages de n’importe quel autre protocole (JMS, FTP, Corba, etc.). Contrairement aux solutions basées sur des Proxy, celles basées sur des Gateways ne se contentent pas d’enrichir l’enveloppe des messages mais elles les ouvrent et les transforment. En conséquence, on a desAPIs non plus accolées à ses applications mais en sortie de la Gateway.

Bien sûr, ces transformations de format de message peuvent avoir un impact sur les temps de réponse de l’API, il faut donc être vigilant sur les performances de la plateforme d’API Management. En termes de performance, la solution de Vordel, désormais Axway, offre des résultats très satisfaisants et se distingue en matière de robustesse et de scalabilité.

Les modes de delivery

Enfin les solutions d’API Management, à l’image de l’ensemble des services applicatifs actuels, proposent des modes de delivery différents : cloud, on premises, voire hybrides.

En conclusion

Choisir une solution d’API Management nécessite tout d’abord de connaître sa maturité interne en matière d’API, cela force également à se demander quels sont les modèles d’affaire que l’on souhaite mettre en place s’il s’agit d’Open API.

Pour faire un choix, on peut également partir de la liste des services des différents vendeurs :

• Est-ce que vos APIs seront utilisées pour développer des applications sur smartphone?
• Comptez-vous utiliser des services de facturation automatique qui vont manipuler des données de cartes bancaires?
• Vos APIs sont-elles déjà développées? Si oui, on n’a pas forcément besoin des solutions orientées Gateways avec des fonctionnalités avancées de transcodage. 
• Se faisant on peut trouver la meilleure solution pour son besoin, mais sans oublier qu’une décision ne se prend pas sur le papier mais en expérimentant. Il faut prévoir différents scénarios que l’on peut dérouler sur une shortlist de vendeurs afin d’évaluer celle avec laquelle on se sent le plus à l’aise.