Compte-rendu du petit-déjeuner “L’API ne fait pas le moine” 19 décembre 2017
Il y a trois ans, OCTO et la tribu WOAPI organisaient un petit déjeuner pour parler des API. Mardi 19 décembre, la tribu remet le couvert pour discuter de ce sujet incontournable dans l’IT aujourd’hui ; entre bête noire des DSI et paradis promis aux développeurs.
“Entre les marrons et les bûches” nous avons partagé nos convictions sur les mythes et les croyances qui entourent l’API, mais aussi nos retours d’expérience sur 4 ans de conseil et de delivery. Qu’en retient-on ?
Retrouvez la présentation complète du petit déjeuner sur SlideShare.
La vidéo du petit-déjeuner est également disponible sur octo.tv
1. API Essentials
Le chantier API est un chantier d’envergure qui est souvent sous-estimé. A travers notre expérience, nous nous sommes proposés d’en définir plus précisément les contours au niveau de la vision, du design, de l’architecture et de l’organisation.
Vision - Une API, why and what?
Deux raisons fondamentales émergent :
Les utilisateurs sont mobiles. Nous devons leur offrir une expérience cohérente entre tous les terminaux qu’ils utilisent : l’API répond à cet enjeu. Un terme résume parfaitement cette nouvelle tendance : ATAWAD (AnyTime, AnyWhere, Any Device). Afin de sortir de l’architecture en silo, qui devient impossible avec la multiplication des terminaux, la solution est d’exposer des ressources sur le web afin qu’elles soient accessibles par ces derniers. L’enjeu est d’exposer des services sans avoir d’a priori sur l’utilisation qui en sera faite. En effet, cette logique métier sera la base solide partagée par tous les fronts, qui eux, sont en explosion avec la multiplication des terminaux.
Jeff Bezos, CEO visionnaire d’Amazon, disait d’ailleurs très tôt que toutes les interfaces devaient être conçues pour être réutilisables à l’extérieur de l’entreprise. Cette stratégie permet d’adresser deux enjeux majeurs pour une entreprise :
- permettre la création de nouveaux business models autour de l’API, en d’autres termes la monétiser, ce qui peut être fait de différentes manières.
- outsourcer l’innovation. Tout développeur ayant accès à l’API peut participer à l’innovation de l’entreprise en créant de nouvelles utilisations ou de nouveaux services se basant sur l’API exposée.
Définition
“L’API est le processus d’industrialisation du processus de consommation des ressources de l’entreprise sur le WEB.”
Les deux concepts fondamentaux de web et d’industrialisation sont au coeur de l’API. L'exposition des ressources de l'entreprise se fait dans un contexte d’ouverture sur le web et doit par conséquent utiliser ses technologies et respecter ses standards. L’industrialisation quand à elle, doit permettre de faciliter l'accès à ces ressources grâce à des outils. Ces outils permettront de déterminer la qualité de votre API et de servir le TTFAC (Time To First API Call, Temps Jusqu’au Premier Appel API), mesure maîtresse dans la définition de qualité d’une API.
Design - Une API, how ?
Une bonne API est une API qui :
- suit les standards HTTP.
The Glory of REST (ou modèle de Richardson) est la base de la réflection pour une API de qualité, l’hypermédia nous ouvrant les portes du paradis.
- s’inspire des Géants du web.
Les développeurs sont habitués à l’utilisation des API phares du web et donc s’attendent dans la vôtre à retrouver les mêmes patterns. L’implémentation de ceux-ci vous donneront de la crédibilité auprès de vos utilisateurs.
- reste simple et externalisable.
Il s’agit d’abstraire la complexité métier afin d’exposer vos ressources d’une manière simple et claire.
- offre une bonne affordance.
Un objet “affordant” est un objet suggérant son utilisation. L'utilisation de votre API doit être intuitive.
Architecture - What of ?
La WOA
L’API est au coeur des architectures d’aujourd’hui. Dans la WOA, les applications front – correspondant aux terminaux utilisateurs – n’ont qu’un seul point d’entrée pour appeler le système d’information. Les développeurs de celles-ci peuvent accéder au portail développeur, premier outil du processus d’industrialisation de l’API. Le point d’entrée du système d’information de l’entreprise se fait par une gateway, interface entre les clients et des microservices participant notamment à la gestion de la sécurité.
SOAP vs REST
C’est un sujet important. Beaucoup de nos clients ont lancé un chantier SOA dans les années 2000. Notre vision : “SOAP is not dead, it is a zombie in the enterprise”. En effet, cette technologie ne pourra pas être supprimée du SI, il faut la faire cohabiter avec le reste d’un SI REST. Il n’y a pas d’outil permettant l’externalisation du SOAP de manière transparente, il faut construire service par service l’exposition de vos ressources suivant l’architecture REST. À noter que plus aucune API des Géants du web n’utilise SOAP à l’exception de PayPal.
API Management
L’API Management est une brique se plaçant entre le client et les backends comprenant 5 fonctionnalités principales :
- gateway
- sécurité
- developer portal
- manager portal
- API façade
Il existe beaucoup de produits sur le marché intégrant ces fonctionnalités. Une solution d’API management clé en main doit être choisie et intégrée avec précaution. En effet, toutes ces fonctionnalités ne seront pas prêtes à l’emploi, ni adaptées à votre situation ou à vos cas d’utilisation. Notamment la façade, nous faisant retomber dans les travers des ESB (SPOF, Vendor Locking…). L’exposition de vos ressources étant un asset différenciant, il sera préférable de l**’intégrer sans l’emploi de progiciels tiers**.
Organisation - une API who ?
L’impact organisationnel est grand lorsqu’on réalise un chantier API. Afin de le mener à bien, nous proposons à nos clients de créer une squad API – squad comme l’entend Spotify : agile, autonome, responsable et pluridisciplinaire. Celle-ci est responsable du produit API. Les développements devront être réalisés verticalement :
- sortir un produit sur un périmètre réduit,
- fonctionnel, fiable, utilisable et avec une bonne Developer eXperience,
- par la suite, scaler sur un périmètre fonctionnel élargi en créant d’autres squads par exemple.
2. Comment sécuriser son API en moins de 30 minutes ?
Lorsqu’on parle de sécurité, on s’attend souvent à rencontrer une panoplie d’outils et de technologies obscures, difficilement accessibles aux néophytes. Lors d’une session de live coding, nos experts nous montrent comment sécuriser une API sur le web en moins de 30 minutes, tout en nous apportant quelques explications sur le framework OAuth 2.0.
Raconte-nous une histoire
Afin de nous aider à mieux comprendre les actions réalisées, nos intervenants se placent dans un cas de figure simple et réaliste. Comment sécuriser les échanges entre une application tierce et une API de e-commerce ouverte sur le web ?
Dans un premier temps, il s’agit de voir comment se comporte l’application lorsqu’aucune sécurité n’est mise en place. C’est simple, n’importe quel utilisateur peut avoir accès à l’ensemble des articles en vente proposés par l’API.
Dans un second temps, il s’agit de sécuriser les échanges en ajoutant une authentification via OpenID Connect, extension du protocole OAuth2.
Un casting de choix
Quels sont les différents acteurs et leurs rôles dans notre scénario ?
En premier lieu nous avons l’utilisateur, le User. C’est la personne physique qui souhaite faire ses achats en ligne. Elle fera ses achats via une application sur le web.
Cette application de e-commerce, on l’appellera le Client.
Ce Client accède aux données d’un Resource Provider. C’est lui qui expose l’API et ses ressources.
Pour finir, un Authorization Server se charge de la partie authentification. C’est un tiers de confiance qui se charge d’identifier le User qui utilisera les ressources du Resource provider à travers le Client.
Et le développeur dans tout ça ? Le développeur joue bien sûr un rôle important. C’est lui qui va rassembler tous les éléments pour donner vie à notre flow d’authentification. Cela se passe essentiellement au sein du code source de l’application et de l’API, objet de ce live-coding.
Live Coding
Pour pouvoir mettre en place la sécurisation de notre API en un temps record, il faut commencer par configurer l’Authorization Server afin qu’il puisse gérer les authentifications de notre utilisateur et lui permettre d’accéder à notre API.
Côté API, le principe est simple. L’API va être modifiée de sorte qu’elle n’accepte plus que des connexions provenant de Clients lui fournissant un jeton d’accès. Pour ce faire, nous ajoutons quelques lignes de code qui indiquent à l’API qu’elle doit désormais vérifier que chaque appel fournisse bien un jeton d’accès. Elle demandera ensuite à l’Authorization Server si c’est bien lui qui a émis ce jeton.
Côté Client, nous allons ajouter une étape d’authentification externe lors de la connexion d’un User. Vous connaissez sans doute le principe. Au moment d’accéder à un site ou une application, vous êtes redirigé vers une mire de login externe afin de vous authentifier. Une fois vos identifiants vérifiés, vous êtes à nouveau redirigés vers votre application tout en étant identifié. C’est exactement ce qui va se passer ici.
Dans le code nous rajoutons une fonction qui indique à l’application Client comment se comporter lors de la connexion d’un User. Elle indique comment authentifier l’utilisateur grâce à l_’Authorization_ Server.
Concrètement, voilà ce que dit cette fonction :
- Moi ‘Application-Client’, je souhaite accéder à l’API e-commerce.
- Si je n’ai pas de jeton d’accès, alors je redirige le User _vers la mire de login de l’_Authorization Server pour récupérerer un jeton d’accès, l’adresse mail du User et le droit d’accéder à la liste de ses commandes.
- Une fois qu’il a authentifié le User_, je veux que l’_Authorization Server renvoie le User vers une de mes URL que j’ai définit.”
Dans cette illustration, le chevalier représente notre User. Son destrier représente le Client c’est-à-dire l’application qui lui servira à faire ses achats en ligne. Enfin, le château fort représente notre Authorization Server.
Notre application Client possède désormais un jeton d’accès valide. Elle va donc pouvoir consommer l’API en lui fournissant ce jeton.
Dernière étape du flow d’authentification, notre API va vérifier ce jeton d’accès auprès de l’Authorization Server pour s’assurer qu’il s’agisse bien d’un jeton valide.
Nous pouvons désormais nous connecter à notre application, voir la liste des produits et consulter nos commandes en toute sécurité.
Définir les droits d’une application
Pour aller plus loin, nous pouvons peaufiner les droits d’accès d’une application. On utilise pour cela les scopes.
Un scope permet de définir des “tranches” de privilèges prêtes à la délégation. C’est une manière de décrire explicitement et de sélectionner un sous-ensemble de droits que l’utilisateur peut consentir à déléguer à l’application.
Vous avez sans doute déjà installé une application Facebook qui vous demande l’autorisation d’accéder à votre liste d’amis ou à votre mur. C’est un exemple d’utilisation des scopes.
Vous pouvez retrouver plus d’informations sur les scopes en consultant notre “Ref-Card” dédiée à la sécurité des API.
A chaque besoin son flow
Le framework OAuth 2 propose plusieurs flows d’authentification correspondant à différents cas d’utilisations, du plus ouvert au plus sensible en terme de sécurité. Pour plus d’informations sur les flow d’authentification, vous pouvez consulter notre “Ref-Card” dédiée à la sécurité des API. Si vous souhaitez approfondir davantage le sujet, un article complet dédié à la sécurité des API sera publié très prochainement.
3. Les API dans la vraie vie (retours d’expérience clients)
Club Med
Enjeux
Nos experts ont aidé les équipes Club Med à opter pour une démarche API first qui consiste à construire un socle ‘API as a product’, proche du métier et bâtir les applications par-dessus (le besoin initialement exprimé était de concevoir un site internet responsive afin d’adresser les terminaux mobiles émergents).
“Baser sa stratégie digitale sur le développement d’interfaces qui se démodent très vite n’est pas une bonne approche. Il convient plutôt de capitaliser sur les services métiers.”
Déroulement de la mission
Constitution d’une SQUAD API (équipe projet dédiée, colocalisée) et développement d’un socle API façade (Trajectoire d'implémentation temporaire qui permet d’aller vite. On y réunit les efforts de DESIGN, de configuration et de sécurisation des API).
Une fois la version 1 de l’API en production, les besoins et priorités ont évolué forçant l’organisation à s’adapter aux nouveaux enjeux business (Component team et Feature team) et voyant l'émergence d’une nouvelle problématique : comment avoir, au sein de la même feature team, 2 produits différents : API et site internet ?
Conclusion
En 4 mois, nous avons développé le MVP (Minimum Viable Product) de l’API correspondant au périmètre fonctionnel exprimé.L’API a permis à Club Med de s’ouvrir à de nouveaux partenaires et d'accélérer radicalement les cycles de livraison du site clubmed.fr.
“L’API n’est pas seulement un produit technique, car il impacte également votre organisation”.
“La Façade doit être une trajectoire d'implémentation temporaire, en aucun cas vue comme une architecture définitive”.
Linxo
Enjeux
Suite à une conférence effectuée par l’un de nos experts dans l'écosystème Open Banking, nous avons été contactés pour les aider à répondre à leurs nouveaux enjeux :
- Développer une OPEN API afin de se positionner au coeur d’une marketplace proposant des services financiers innovants.
- Se positionner comme identité pivot pour les plateformes financières.
Déroulement de la mission :
Constitution d’une SQUAD API et développement d’un socle API façade.
L’API a été développée sur des services existants statefull et très complexes à consommer. La sécurisation (OpenID connect) a été un sujet délicat (branchements internes de la spécification OIDC) afin de respecter les fortes contraintes du SI LINXO.
Conclusion
En 5 mois nous avons développé une API REST (façade), exposant 15 ressources sécurisées par le framework Open ID connect. LINXO a aujourd’hui toutes les compétences et connaissances nécessaires pour faire évoluer son produit API.
“Aller sur internet, reste une question délicate pour nos clients”.
“Il n’existe pas de solution de API Management plug and play qui réponde à des enjeux fort comme LINXO. Il faut crafter son API”.
AXA partners
Enjeux
Répondre à un enjeu business important pour AXA en permettant à ses clients de consulter leurs organismes de santé partenaires lors de leurs déplacements. Nos experts ont réalisé un produit API pour permettre aux applications mobiles de consommer les services AXA.
Déroulement de la mission
Constitution d’une équipe mixte OCTO/AXA (développeur, PO, OPS) et développement d’un socle API façade. Utilisation d’un management entièrement visuel (aucun outil en ligne) et coaching intensif des équipes. Intégration sans douleur d’une nouvelle stack technique (Node.js) afin d’accélérer le time-to-market (existant 100 % Microsoft).
Conclusion
La réussite de cette mission a été largement tributaire d’un fort sponsorship.
En 3 mois, nous avons levé les contraintes techniques existantes avec l’aide de l’équipe interne et créé une API façade exposée via un portail développeur (Le TTFAC, temps moyen d'enrôlement sur le portail développeur de l’API, est de 15 minutes).
“API-ser tout son SI, c’est long lorsqu’on veut bien faire”.
4. Sept convictions autour de l’API
Partageons maintenant quelques convictions qui peuvent paraître de prime abord un peu brutes. Même si cela peut être ressenti comme une utopie, elles constituent un cadre de référence de l’état de l’art.
Une sorte de grille de lecture qui permet de nous challenger et produire les meilleures API possibles. C’est un idéal vers lequel nous voulons tendre.
# 1 Si vous n’offrez pas une Open API quelqu’un le fera à votre place...
…et en tirera les bénéfices ! Les données que vous exposez sur vos sites web, même derrière une identification, sont faciles à extraire. Les solutions de scrapping sont nombreuses, certaines même en SaaS, ce qui ne prend que quelques heures à automatiser.
De nombreux acteurs comme Google “volent” déjà vos données. Dans le secteur bancaire, des acteurs comme Linxo récupèrent les données les plus fraîches en simulant une connexion utilisateur et en “scrapant” le contenu.
# 2 Ouvrez vos APIs sur internet
Il existe une vrai crainte au moment d’ouvrir nos APIs sur Internet. D’où vient cette appréhension ?
Jusqu’à maintenant, on construisait des forteresses – firewall, vpn, etc – pour protéger ses services. Or, si on trouve un moyen de franchir ces forteresses, l’accès aux données est ouvert. Avec la multiplication des usages et des terminaux, cette manière de sécuriser est devenue intenable. Par ailleurs 3/4 des vols de données se font par des personnes qui sont à l'intérieur de votre SI.
La tendance est d’aller vers de la sécurité applicative. Chaque service est sécurisé à la source et a pour charge de vérifier l’identité et les autorisations des applications qui l’appellent.
Cela étant fait, on peut considérer tout usage et exposition de manière égale. S’éloigner ainsi de la traditionnelle distinction internet/intranet qui introduit plus de complexité que de bénéfices. “One channel to rule them all: the Internet!” L’esprit même des architectures orientée WEB qui infiltrent nos SI.
# 3 Une stratégie d'API est d’abord un sujet culturel et organisationnel
La loi de Conway (1969) disant que “tout système reflète l'organisation qui l'a créé” est toujours d’actualité. La technique devient secondaire. Le plus grand challenge concerne l’organisation de ses équipes et les méthodologies adoptées. Un quick-win est l’utilisation de squads (pizza team).
# 4 L'API n'est pas un progiciel (d’API Management)
Votre stratégie ne doit pas se résumer à l’achat d’une solution d'APIM, dont les nombreuses fonctionnalités proposées semblent résoudre tous les problèmes (de la sécurité, au transcodage en passant par l’administration).
L'APIM est la partie immergée de l'iceberg et ne couvre que 10 % des besoins. Nous en avons besoin pour enrôler les développeurs et leur présenter un portail de documentation. Cet outil peut prendre en charge une partie de la sécurité mais attention, il y aura beaucoup de chantiers cachés ; notamment organisationnels, business, sécurisation à la source, performances et disponibilités.
Il est intéressant également de jeter un coup d’œil dans le rétroviseur et de faire attention à la concentration du pouvoir dans un seul outil. #RappelleToiLesESBs
# 5 L'API est un produit
L’API devrait être conçue avec une vision produit et non projet :
- Budget variable
- Réutilisable
- Conduit par les résultats
- Se termine quand il n’y a plus de besoin clients
- Focus sur le client
- Marketing évangélique
Stripe, une solution de paiement en ligne (valorisée 10 milliards), annonce dès sa page d’accueil sa “priorité aux développeurs”. Nous y voyons quelques lignes de code et les liens directs vers la documentation. Le TTFAC est de moins de 30 minutes, là où les solutions bancaires comptent plusieurs jours.
# 6 La façade est faite pour disparaître
D’un point de vue organisationnel, le pattern façade permet d’exposer sous forme d’API un service situé au fin fond du SI de manière assez rapide (en 3 ou 4 mois pour donner un ordre d’idée). Avec le temps cependant, des problèmes et frictions commencent à émerger. Souvent l’équipe du SI fonctionne en cycle en V, tandis que l’équipe qui a travaillé sur l’API utilise les méthodes agiles. On observe aussi des différences de temporalités opposées avec un SI qui ferme la nuit pour faire tourner des batchs et une API qui doit être disponible H24 et 7/7 pour ses consommateurs. L’équipe façade se retrouve vite entre le marteau et l’enclume !
S’il n’existe pas de baguette magique pour résoudre ces problèmes, on peut néanmoins préconiser de faire redescendre les API au cœur du SI.
# 7 L’API hypermedia est à tester
La matrice de maturité de Richardson présentée en 2008 présente 4 niveaux de maturité d’une API. 10 ans après, seulement 5 % des open API atteignent le dernier niveau, l’hypermedia, pour les raisons suivantes :
- Il n’existe pas de format (media type) unique.
- Il existe peu de frameworks et d’outils.
- HTTP et les URI font déjà beaucoup pour REST (disons 80 % de la valeur totale).
- Il manque des exemples et des success stories.
Nous avons testé une implémentation de l’hypermedia chez OCTO et notre avis est plutôt positif :
- C’est simple à mettre en place sur une API déjà existante.
- Cela permet une compatibilité ascendante via le pattern représentant.
- Cela offre une meilleure affordance et évolutivité.
Si le sujet vous intéresse, vous pouvez consulter notre article sur l’hypermedia.
Et n’oubliez pas :
_“_Si votre métier est compliqué, votre API le sera aussi”.