Compte-rendu du petit-déjeuner : dessine-moi une API… et dis-moi comment la manager !

Intervenant :

Christian Fauré, Manager chez OCTO Technology

Agenda :

  • Distinguer les démarches OpenData et OpenAPI
  • La conception des APIs Hypermedia
  • Panorama des solutions d’API Management

 

Distinguer les démarches OpenAPI et OpenData

 Les Démarches OpenData :

  • Elles consistent à publier des jeux de données ;
  • Pour que ces corpus de données publiées puissent être facilement réutilisés, il faut que les données soient les plus auto-descriptives (que leur sémantique soit non ambiguë) ;
  •  Les formats doivent être facilement manipulables par des développeurs tiers.
  • Il s’agit de publier un catalogue de données

Les démarches Open API :

  • Elles consistent à publier des interfaces pour accéder aux données.
  • Les requêtes à l’API doivent être les plus simples possibles si on veut en favoriser l’usage
  • Il s’agit de publier un catalogue de requête

 

Les démarches OpenAPI et OpenData sont toutes deux des démarches de publication des ressources digitales de l’entreprise, mais elles différent sur les points suivants :

  • Publier des corpus de données nécessite une forte culture dans les formats de description des métadonnées (RDF)
  • Les modèles économiques de l’OpenData sont des modèles académiques et institutionnels à long terme, là ou les modèles économiques de l’OpenAPI relèvent de la rentabilité à court et moyen terme.
  • L’OpenData est généralement un modèle en lecture seule ; l’OpenAPI est en lecture et écriture.
  • Les architectures OpenData ne sont pas adaptées à des enjeux de vitesse et de scalabilité dans l’accès aux données publiées.

Les démarches OpenAPI sont devenues majoritaires ; même pour publier des données on tend à privilégier des APIs comme mode d’accès à des « données brutes ».

 

La conception des APIs Hypermedia

Ne pas oublier que la seule chose qu’un Client voit d’une API c’est le message de réponse du serveur : toute l’intelligence d’une API réside dans les messages.

Évolution des APIs RESTful :

  • Niveau 0 : approche SOAP et XML
  • Niveau 1 : focus sur les Ressources (ROA : Ressources Oriented Applications)
  • Niveau 2 : focus sur les Verbes http (WOA : Web Oriented Architecture)
  • Niveau 3 : prise en compte des messages et des hyperliens (Hypermedia Oriented Architecture)

L’enjeu des messages :

  • Prendre en compte le principe HATEAOS (Hypermedia as the engine of application State) de Roy Fielding ;
  • Si l’on veut bénéficier des liens hypermedias il faut privilégier des formats de fichiers qui supportent en natif les liens : or XML et JSON ne supportent en natif aucun lien !
  • Mike Amundsen à proposé une classification des Media types (format de fichiers) selon la nature des liens qu’ils permettent : Hypermedia Factors

 

Démarche de conception des APIs Hypermedia :

  • Ne pas oublier de faire un diagramme d’état lors de la conception de l’API pour pouvoir choisir plus judicieusement le format de fichier le plus approprié pour son API.

 

Panorama des solutions d’API Management

Le marché des solutions de Management d’interfaces de programmation applicatives (API management), tout en étant en voie de d’homogénéisation et de consolidation, n’en reste pas moins assez hétérogène.

Il 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’APIs Management : elles proposent 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. Dans cet article, nous vous livrerons quelques éléments qui permettent de différencier les offres de Management d’API.

C’est un marché qui 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 nous pouvons distinguer 4 tendances :

  • la première tendance est celle qui fera l’objet de notre propos, 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 d’API et à leur management, 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

Schéma 1

 

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 de l’API Management.

Sans titre2

 

L’architecture fonctionnelle des solutions d’API Management

Ces solutions comprennent trois briques :

Sans titre3

 

On peut ainsi représenter l’architecture fonctionnelle des solutions d’API Management de la façon suivante :

Sans titre4 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 que nous reprenons et enrichissons ci-après. Celle-ci se concentre sur le composant “Gateway” des offres d’API Management.

Nous distinguons donc trois types d’architecture : la première consiste à installer un module ou connecteur dans votre 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 votre API soit bien conçue mais aussi que vous preniez en charge vous-même sa publication (3Scale peut s’utiliser avec Nginx pour ajouter un proxy Open Source à votre 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 vous ayez bien conçu votre 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 dites de “médiation”, c’est-à-dire de transcodage des messages permettant de transformer une API SOAP-XML en REST-JSON, mais n’en espérez pas trop.

Pour aller plus loin en terme de transformation et d’enrichissement de votre API, il vous faudra regarder du côté des Gateways.

Avec les solutions basées sur une Gateway, vous aurez 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 l’ouvrent et le transforment. En conséquence, vous aurez vos APIs non plus accolées à vos 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 votre API, il faudra donc être vigilant sur les performances de la plateforme d’API Management. En terme 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é.

Sans titre5

 

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. Nous avons croisé dans le tableau ci-après les principales offres selon le critère de l’architecture technique et du mode de delivery :

Sans titre6

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 vous souhaitez mettre en place s’il s’agit d’Open API.

Pour vous aider à faire un choix, vous pouvez é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 vous n’aurez pas forcément besoin des solutions orientées Gateways avec des fonctionnalités avancées de transcodage.
  • Se faisant vous trouverez la meilleure solution pour votre besoin, mais sans oublier qu’une décision ne se prend pas sur le papier mais en expérimentant. Prévoyez différents scénarios que vous pourrez dérouler sur une short-list de vendeurs afin d’évaluer celle avec laquelle vous vous sentez la plus à l’aise

 

Retrouvez les slides de la présentation sur notre Slideshare !