Toan Nguyen, PDG de Shortways
Exemple :
• Le bouton « like » de Facebook que l’on retrouve sur bon nombre de pages web adresse une API de Facebook : lorsqu'on like une page du Monde.fr, le site web du Monde.fr envoie une instruction à Facebook -via l'API donc- pour poster l'article sur votre profil Facebook.
• Twitter a démarré essentiellement comme service API. De nombreux logiciels clients (TweetDeck, etc.) se sont greffés par-dessus.
• Le cloud AWS d’Amazon est entièrement adressable par des APIs
La philosophie des APIs : un changement de paradigme
Quand on parle d’APIs, on peut penser qu’il s’agit exclusivement d’un sujet technique, mais on parle en fait des acteurs suivants, excusez du peu ! : Amazon, Salesforce, Twitter, Expedia, Twillio, …
Quelques chiffres pour réaliser l’ampleur du mouvement :
• 50% des transactions sur Salesforce sont réalisées par le biais d’APIs ! (pas par des utilisateurs directs de l’application web donc)
• Réserver un hôtel ou un billet d’avion sur Expedia se fait exclusivement par des APIs (c’est pour cela que vous pouvez le faire depuis le site de voyages-sncf par exemple)
• Il y a plusieurs milliers d’API publiques (et autant voire plus de privées) aujourd’hui
Qu’est-ce que cela veut dire ? Que c’est le web entier qui est en train de s’organiser sous forme de service et d’applications (ça c’est le phénomène Facebook/Apple Store pour le grand public et SaaS pour le B2B), et que surtout on connecte ces services entre eux (par le biais des APIs donc) pour recréer de nouveaux services (on appelait cela des mash-ups avant).
N’importe qui peut donc programmer une nouvelle application qui s’appuie des services fournis par d’autres éditeurs.
Imaginez par exemple un super ERP qui s’appuie sur les services Salesforce pour la gestion commerciale, Taleo pour les RH, OpenERP pour la compta, Basecamp pour la gestion de projet, etc…
Il « suffirait » de s’appuyer sur les meilleurs services pour créer les meilleurs applications. On est très loin de la vision monolithique client/serveur de SAP !
Exposer une API
Pour les évangélistes, l’API est un produit et un business model en soit, une formidable levier de business puisqu’on va pouvoir générer du trafic, des transactions sur son service grâce à d’autres acteurs qui auront construit des applications dessus.
Il ne s’agit donc plus seulement d’exposer techniquement une API : il faut savoir
• à qui on l’expose (les clients),
• qu’est-ce qu’on expose (le produit, les données ?). En général un service très simple, c'est à dire le cœur de de service de l’éditeur de logiciel,
• sous quelle forme on facture (à l’usage pay-as-you-go, abonnement, modèle freemium, etc.)
API signifie en fait : Apps, Partners, Income !
Il y a plusieurs types d’APIs selon qu'elles mettent à disposition :
• le contenu (ex : une vidéo Youtube)
• un produit ou service complet (ex : Mailjet le service d’envoi de mails)
• un moyen d'exposer les produits des autres (ex : la place de marché Amazon ou d'ebay qui permet de vendre des produits fabriqués ou vendus par des milliers de marchands).
D’un point de vue client final ou développeur utiliser une API, c’est externaliser une partie de son service, en général ce qui ne relève pas de son cœur de métier.
De fait, quand on parle d’externaliser, il faut un service/API : fiable, sécurisé, et dont on connaît exactement les tenants et aboutissants.
Gérer opérationnellement une API
C’est pourquoi la mise sur le marché d’une API doit s’appuyer sur une structure opérationnelle solide :
• une gestion de la sécurité d’accès
• un SLA (Service Level Agreement)
• une surveillance du trafic pour réagir en cas de pic exceptionnel
• de la qualité de service (QoS) pour prioriser certains contenus par rapport à d’autres, même si une API est par principe « égalitaire » devant chaque client.
• du provisioning (être sûr qu’on a toujours la bonne capacité serveur pour délivrer le service…)
• une bonne documentation, car l’API s’adresse à des développeurs. Pas de bonne documentation = pas de code = pas de clients !
• des "Terms of Service" (Conditions Générales) appropriés
• un gestionnaire de facturation
Il est important pour maîtriser le niveau de service que l’API soit scalable, c’est-à-dire capable d’absorber les montées en charge de trafic. La recommandation en ce sens est d’avoir une API simple par fonction exposée, de façon à pouvoir la « répliquer ». Une grosse API multi-fonctions se révèlerait difficile à maitriser dès lors que le volume de trafic augmente.
Il existe quelques acteurs, éditeurs de plateforme d’API Management, qui permettent de gérer tout cela : 3scale (voir leur excellent topo sur les API ici), 7Layer, SOA Management.
Il faut également regarder du côté des acteurs du Cloud IaaS : Azure, Amazon AWS qui doivent plus ou moins déjà proposer ce type de service ? (à confirmer…).
Apparemment, ce type de solution s’adresse surtout à des éditeurs « mûrs » qui décident d’exposer un de leur service sous forme d’API (moins à des start-up).
Les pièges
Il a bien sûr des pièges et des faiblesses :
• l’explosion du phénomène est récente. Il n’y a donc aucun standard. Il faut apprendre et comprendre comment ça marche à chaque fois que l’on veut intégrer une nouvelle API (d’où l’importance de la documentation…),
• chaque éditeur d’API a sa propre politique juridique et financière qu’il est libre de changer quand il le veut (témoin le récent changement de l’utilisation de l’API de Twitter qui a largement modifié son ecosystème),
• enfin chaque éditeur a sa propre philosophie d’API : si la première version de l’API Salesforce fonctionne encore, Facebook change lui ses APIs toutes les 2 semaines, avec parfois plusieurs versions en production de la même API…
Il est donc dangereux de s’appuyer exclusivement sur une API pour monter son business (ou en tous cas il faut être très très réactif). Encore une fois l’exemple de Twitter l’a montré.
Les opportunités
Si j’ai pris la peine d’écrire un article sur le sujet, c’est qu’à mon sens, il y a biensûr plus d’opportunités que de faiblesses !
Notamment apparaissent sur le marché des initiatives de fédérer ces APIs :
• les catalogues (programmableweb)
• les plateformes qui intègrent les API sous une seule API (webshell.io, co-organisateur de la 1ère conférence en Europe API Days sur les APIs qui a eu lieu en décembre 2012 dernier)
• des démarches de standardisation ?
Mais surtout, c’est une tendance lourde drivée par les poids lourds du web (Amazon, twitter, salesforce, …)
Exister sur le web sans API n’est plus concevable car pas d’API = pas d’écosystème.
Bonnes APIs à tous !
• Le bouton « like » de Facebook que l’on retrouve sur bon nombre de pages web adresse une API de Facebook : lorsqu'on like une page du Monde.fr, le site web du Monde.fr envoie une instruction à Facebook -via l'API donc- pour poster l'article sur votre profil Facebook.
• Twitter a démarré essentiellement comme service API. De nombreux logiciels clients (TweetDeck, etc.) se sont greffés par-dessus.
• Le cloud AWS d’Amazon est entièrement adressable par des APIs
La philosophie des APIs : un changement de paradigme
Quand on parle d’APIs, on peut penser qu’il s’agit exclusivement d’un sujet technique, mais on parle en fait des acteurs suivants, excusez du peu ! : Amazon, Salesforce, Twitter, Expedia, Twillio, …
Quelques chiffres pour réaliser l’ampleur du mouvement :
• 50% des transactions sur Salesforce sont réalisées par le biais d’APIs ! (pas par des utilisateurs directs de l’application web donc)
• Réserver un hôtel ou un billet d’avion sur Expedia se fait exclusivement par des APIs (c’est pour cela que vous pouvez le faire depuis le site de voyages-sncf par exemple)
• Il y a plusieurs milliers d’API publiques (et autant voire plus de privées) aujourd’hui
Qu’est-ce que cela veut dire ? Que c’est le web entier qui est en train de s’organiser sous forme de service et d’applications (ça c’est le phénomène Facebook/Apple Store pour le grand public et SaaS pour le B2B), et que surtout on connecte ces services entre eux (par le biais des APIs donc) pour recréer de nouveaux services (on appelait cela des mash-ups avant).
N’importe qui peut donc programmer une nouvelle application qui s’appuie des services fournis par d’autres éditeurs.
Imaginez par exemple un super ERP qui s’appuie sur les services Salesforce pour la gestion commerciale, Taleo pour les RH, OpenERP pour la compta, Basecamp pour la gestion de projet, etc…
Il « suffirait » de s’appuyer sur les meilleurs services pour créer les meilleurs applications. On est très loin de la vision monolithique client/serveur de SAP !
Exposer une API
Pour les évangélistes, l’API est un produit et un business model en soit, une formidable levier de business puisqu’on va pouvoir générer du trafic, des transactions sur son service grâce à d’autres acteurs qui auront construit des applications dessus.
Il ne s’agit donc plus seulement d’exposer techniquement une API : il faut savoir
• à qui on l’expose (les clients),
• qu’est-ce qu’on expose (le produit, les données ?). En général un service très simple, c'est à dire le cœur de de service de l’éditeur de logiciel,
• sous quelle forme on facture (à l’usage pay-as-you-go, abonnement, modèle freemium, etc.)
API signifie en fait : Apps, Partners, Income !
Il y a plusieurs types d’APIs selon qu'elles mettent à disposition :
• le contenu (ex : une vidéo Youtube)
• un produit ou service complet (ex : Mailjet le service d’envoi de mails)
• un moyen d'exposer les produits des autres (ex : la place de marché Amazon ou d'ebay qui permet de vendre des produits fabriqués ou vendus par des milliers de marchands).
D’un point de vue client final ou développeur utiliser une API, c’est externaliser une partie de son service, en général ce qui ne relève pas de son cœur de métier.
De fait, quand on parle d’externaliser, il faut un service/API : fiable, sécurisé, et dont on connaît exactement les tenants et aboutissants.
Gérer opérationnellement une API
C’est pourquoi la mise sur le marché d’une API doit s’appuyer sur une structure opérationnelle solide :
• une gestion de la sécurité d’accès
• un SLA (Service Level Agreement)
• une surveillance du trafic pour réagir en cas de pic exceptionnel
• de la qualité de service (QoS) pour prioriser certains contenus par rapport à d’autres, même si une API est par principe « égalitaire » devant chaque client.
• du provisioning (être sûr qu’on a toujours la bonne capacité serveur pour délivrer le service…)
• une bonne documentation, car l’API s’adresse à des développeurs. Pas de bonne documentation = pas de code = pas de clients !
• des "Terms of Service" (Conditions Générales) appropriés
• un gestionnaire de facturation
Il est important pour maîtriser le niveau de service que l’API soit scalable, c’est-à-dire capable d’absorber les montées en charge de trafic. La recommandation en ce sens est d’avoir une API simple par fonction exposée, de façon à pouvoir la « répliquer ». Une grosse API multi-fonctions se révèlerait difficile à maitriser dès lors que le volume de trafic augmente.
Il existe quelques acteurs, éditeurs de plateforme d’API Management, qui permettent de gérer tout cela : 3scale (voir leur excellent topo sur les API ici), 7Layer, SOA Management.
Il faut également regarder du côté des acteurs du Cloud IaaS : Azure, Amazon AWS qui doivent plus ou moins déjà proposer ce type de service ? (à confirmer…).
Apparemment, ce type de solution s’adresse surtout à des éditeurs « mûrs » qui décident d’exposer un de leur service sous forme d’API (moins à des start-up).
Les pièges
Il a bien sûr des pièges et des faiblesses :
• l’explosion du phénomène est récente. Il n’y a donc aucun standard. Il faut apprendre et comprendre comment ça marche à chaque fois que l’on veut intégrer une nouvelle API (d’où l’importance de la documentation…),
• chaque éditeur d’API a sa propre politique juridique et financière qu’il est libre de changer quand il le veut (témoin le récent changement de l’utilisation de l’API de Twitter qui a largement modifié son ecosystème),
• enfin chaque éditeur a sa propre philosophie d’API : si la première version de l’API Salesforce fonctionne encore, Facebook change lui ses APIs toutes les 2 semaines, avec parfois plusieurs versions en production de la même API…
Il est donc dangereux de s’appuyer exclusivement sur une API pour monter son business (ou en tous cas il faut être très très réactif). Encore une fois l’exemple de Twitter l’a montré.
Les opportunités
Si j’ai pris la peine d’écrire un article sur le sujet, c’est qu’à mon sens, il y a biensûr plus d’opportunités que de faiblesses !
Notamment apparaissent sur le marché des initiatives de fédérer ces APIs :
• les catalogues (programmableweb)
• les plateformes qui intègrent les API sous une seule API (webshell.io, co-organisateur de la 1ère conférence en Europe API Days sur les APIs qui a eu lieu en décembre 2012 dernier)
• des démarches de standardisation ?
Mais surtout, c’est une tendance lourde drivée par les poids lourds du web (Amazon, twitter, salesforce, …)
Exister sur le web sans API n’est plus concevable car pas d’API = pas d’écosystème.
Bonnes APIs à tous !