Le décor est planté, la pause terminée. L'assistance se rassoit tandis que s'avancent les deux challengers, j'ai nommé Adrien Graux et Daniel Sabin. Les deux champions, fébriles, montent sur le ring, là où plusieurs conférenciers posèrent le pied avant eux. Plus tôt dans la matinée, certains parlaient d’ESB, prémices de l’API Management. Ce dernier est né de nouveaux besoins utilisateurs, pour lesquels les éditeurs promettaient monts et merveilles.

Mais qu’en est-il vraiment ?

Nos experts ont synthétisé pour vous les promesses des plateformes du marché en une analyse claire et concise. Attachez vos ceintures et remontez vos tablettes, le décollage est imminent !

L’API Management est le processus de publication, de promotion et de supervision d’une API. Il comporte un ensemble d’outils destinés à gérer les identités et la sécurité (IAM ou Identity and Access Management), le routage des requêtes/réponses (la gateway), la consommation des API (portail développeur) et leur publication (portail de management). Ces deux portails forment parfois un seul et même outil.

Promesse n° 1

Get started in 1 minute. Une fois votre solution déployée, publier votre première API est simple et rapide, voire même intuitif. La promesse est tenue puisque la majorité des solutions que nos experts ont rencontrées jouent le jeu.

D’autre part, Daniel et Adrien préconisent une solution entièrement pilotable par API. Cela permet à votre équipe Ops d’automatiser la configuration de la plateforme d’APIM par un procédé nommé infra-as-code.

Promesse n° 2

Transformation de vos services. La proposition est alléchante mais on s’en mord vite les doigts. Transformer vos vieux services en API REST toute belle, toute propre, et bien brillante qui plus est. “Ici, le constat est mitigé”, nous dit Adrien.

Bien que vous n’ayez pas d’API, il est possible de transformer vos services existants (souvent en SOAP) en API REST flambant neuve. Mais quid du design, des performances, de la documentation ? Comment assurer une developer experience digne de ce nom si d’ores et déjà vous mettez la poussière sous le tapis ?

Nos experts ajoutent que le design et l’exposition se font à 100% dans l’outil, ce qui accroît le vendor locking (lorsqu’on est prisonnier d’une techno propriétaire, non standard).  On finit par mettre du métier dans une gateway dite "technique". De plus, cela empêche une scalabilité efficace.

Finalement, cette solution convient bien aux besoins de transformation rapide de flux. Cela permet de mettre en place une façade sur des vieux services mais ce ne doit pas être une finalité. Si votre métier se reposent sur des vrais besoins en terme d’API, une implémentation personnalisée sera nécessaire.

La gateway peut se résumer à un proxy de luxe qui :

• traite une requête
• la passe au service sous-jacent
• reçoit la réponse
• transforme éventuellement la réponse
• retourne la réponse au client

Promesse n° 3

OAuth2 et OpenID Connect. Protéger vos API, clé en main. Voici la promesse des solutions. La majorité des solutions disposent d'un serveur d'autorisation dans la gateway. Elles font parfaitement leur travail dans les cas simples : clé d’API et jeton d’accès serveur à serveur (client credentials). Ces stratégies de sécurisation n’incluent pas d’authentification de l’utilisateur final. Il est à noter que les solutions du marché répondent mal à ce dernier besoin, la promesse est donc rompue.

Chaque API devra être indépendante et assurer sa propre sécurité. Elle devra rester agnostique des couches au-dessus d’elle. Ainsi la gateway effectuera une validation technique (le token est-il valide, non expiré, etc.) et l’API effectuera une validation technique et fonctionnelle (le token est-il valide, le scope nécessaire est-il présent pour appeler cette route, etc.).

La préconisation d’architecture sera de laisser chaque brique faire ce qu’elle fait le mieux. Par exemple, disposer d’une solution d’IAM dédiée comme Auth0, Keycloak ou autre.

Promesse n° 4

Portail développeur personnalisable. Le portail développeur est la vitrine de votre métier. Il doit donc refléter à 100% votre entreprise et vos produits. On nous promet sur le marché que le portail développeur est prêt à l’emploi. Il suffirait simplement de peindre les murs et poser des joints pour étanchéifier le tout. La pratique est un peu différente de la théorie…

En réalité, il est vrai que publier la documentation globale (sécurité, guides) est simple. On peut créer un compte, publier la documentation OpenAPI, créer des clients sécurisés (via API key et flow OAuth2 Client Credentials) pour consommer les API. On peut même se connecter avec GitHub, GMail ou un compte interne LDAP.

Là où ça devient plus compliqué, c’est quand les besoins sont plus poussés que les cas ci-dessus. Difficile de maintenir un code homemade dans une solution qui ne nous propose qu’un long champ de formulaire textuel, où on colle tout son CSS, son HTML et son JS. On ne profite aucunement de nos outils de déploiement continu tels que les tests automatisés, la CI/CD… La plupart ne proposent pas la gestion de plusieurs organisations différentes — pourtant bien pratique lorsque l’on ouvre une API à des partenaires — ou encore le partage d’application entre développeurs de la même organisation.

Un portail développeur clé en main peut donc être utilisable, à la condition que les besoins soient triviaux. Le portail développeur vous représente. “Pas le choix, il faut développer le portail [développeur]”, insiste Adrien.

Promesse n° 5

Analytics intégré. Les métriques de la consommation de vos API doivent être clairement exposées pour faciliter leur monitoring. En pratique, l’effet démo est garanti. Les dashboards sont généralement beaux. Mais les métriques standards sont rarement suffisantes, peu paramétrables et parfois même inutiles. De plus, la durée de rétention est limitée (1 jour pour Kong par exemple).

Pour bien faire, il faudrait extraire les données et les logs et faire ses propres statistiques. Daniel et Adrien ont souvent mis en place ElasticSearch et Kibana qui répondent à la plupart des besoins.

Promesse n° 6

Plusieurs environnements pour vos API. Publier vos API en test avant publication en production est une nécessité pour en assurer la qualité. Ceci répond au besoin de test des développeurs de l’API et de l’équipe qui gère l’APIM, et non des consommateurs. “En tant que consommateur, j’ai besoin d’un environnement bac à sable (sandbox) identique à la production. Qui a déjà appelé les API de dév. de Google ?”, rappelle Daniel.

Il s’agit de définir une stratégie pour faciliter le développement des applications partenaires. On mettra donc à disposition un environnement de sandbox, stable, cohérent et identique à la production. A ceci près que ses appels externes — i.e. à d’autres API — devront être bouchonnés. Ce n’est pas à la solution d’APIM de proposer un environnement de sandbox mais bien un développement dédié.

Bilan

L’heure est au bilan et il est partagé. Environ 60% des promesses sont tenues. L’important est d’identifier ses besoins et de comprendre comment tirer parti des meilleures solutions, en les combinant. Le build vs buy est votre driver pour avancer dans l’exposition de vos API.

Take away

• Posez vous la question: est-ce pertinent de personnaliser une solution d’API Management ?
• Usages B2C: utiliser une solution IAM externe
• Les API devront être buildées et sont responsables de leur propre sécurité métier
• Ne pas négliger la gouvernance de vos API
• Le portail développeur est un différenciant, il faudra le développer
• Ne suivez pas les solutions les yeux fermés

Ne manquez pas notre nouvelle reference card sur l'API Management et son site associé pour vous aider à choisir la plateforme qui vous convient !

https://www.youtube.com/watch?v=3Lrmi5NOdxU