API : point-clé du succès de votre application en SaaS

Les APIs sont indispensables aux applications SaaS : elles rendent le service utilisable, intégrable et monétisable. Mais quels choix techniques (cryptage, authentification, versioning, etc.) effectuer pour avoir une API efficace ? Quel business model utiliser pour en faire une source de revenu importante ?

Transcript

1. Les APIs points-clés de la réussite d'une application en SaaS Créé par / David Loureiro @DavidLoureiroFr
2. Plan Introduction Les APIs pour quoi faire ? Comprendre la chaîne de valeur des APIs Publique vs Privée Les Business models d'API Mise en place de l'API Sécurité Aspects légaux Contrôle et analytics Adoption de votre API
3. Me, myself and SysFera Ok, un peu présomptueux... ...mais ce sera court !
4. David Loureiro Président de SysFera Formation d’ingénieur en mathématiques appliquées Issu de l’EM Lyon Expertise sur les problématiques SaaS, Cloud, Open Source et HPC Blogs : Twitter : blog.sysfera.com mag.welovesaas.com @DavidLoureiroFr @SysFera
5. SysFera Éditeur de logiciels Missions : aider les éditeurs et les gestionnaires d’infrastructures à adopter un Business Model SaaS Références :
6. Des APIs pour faire quoi ? Application Programming Interface crédits : WeLoveSaaS
7. Une API suit une spécification Le fournisseur de l'API doit : décrire les fonctionnalités offertes en donner la disponibilité en gérer la compatibilité préciser les contraintes d'utilisation techniques et légales Le développeur doit respecter ce cadre.
8. Le fournisseur peut aussi devoir fournir : un moyen d'accéder et de comprendre les conditions d'utilisation une documentation pour aider à comprendre et utiliser l'API des ressources pour offrir un support aux développeurs des informations sur la 'santé' de l'API et la façon dont elle est actuellement utilisée
9. Attention : Changement d'implémentation != Changement d'interface Changement d'interface = Changement de contrat
10. Une API doit être disponible 24/7/365 Les changements ne sont pas le Mal ! Les changements peuvent être imposés par l'usage qui est fait de votre API
11. Qui utilise une API ? crédits : WeLoveSaaS
12. Types d'API API Publique API Privée
13. crédits : ProgrammableWeb
14. Une API = une stratégie Cause : explosion de l'usage d'applications et des smartphones Conséquence : explosion du modèle Certaines applications n'ont même pas d'interface web ! crédits : "APIs : a Strategy Guide"
15. Les APIs forment le backend de vos applications Vous pouvez ainsi offrir une expérience identique sur tous les terminaux possibles.
16. Quelques chiffres Twitter : 15 milliards d'appels par jour : 75% à travers l'API (juin 2011) Amazon Web Services : 260 milliards d'objets stockés dans S3 (janvier 2011) Google ou Facebook : > 5 milliards d'appels à l'API par jour
17. Pourquoi une API ? Application mobile Demande de client ou de partenaire Besoin de mieux délivrer votre contenu Vos concurrent ont des APIs
18. À quoi sert une API ? Atteindre plus d'utilisateurs/clients Générer des revenus indirects Accroître l'innovation à travers vos partenaires Augmenter la valeur d'autres applications à travers l'intégration Permettre un usage freemium de vos solutions
19. Canal de distribution Vos sites, applications, etc. sont des canaux de distribution directe de votre contenu ou service Les APIs sont, par esssence, un canal de distribution indirecte de votre contenu
20. crédits : "APIs: a Strategy Guide"
21. Chaîne de valeur Quand une stratégie d'API échoue, cela vient souvent du fait qu'un ou plusieur des liens de cette chaîne est trop faible pour supporter la création d'un business autour de l'API.
22. API publique ou privée ?
23. API publique API disponible avec peu, voire pas, d'arrangement contractuel avec le fournisseur (autre que les conditions d'utilisation).
24. Chaîne de valeur Le détenteur des assets veut élargir l'audience de ses contenus et ouvrir de nouveaux marchés Il doit incentiver les développeurs Les applications doivent avoir un canal de distribution pour trouver un public.
25. Usages de l'API Augmenter la valeur et étendre une marque Atteindre des marchés de niche Augmenter l'accès à vos applications à travers les plates- formes et les terminaux Supporter l'innovation
26. Risques Ne pas se tromper : l'intérêt vient des assets pas de l'API elle- même Risques légaux Votre infrastructure technique va-t-elle tenir ? Faites attention à ce que votre core business ne se fasse pas cannibaliser Surexposition de vos assets à vos compétiteurs
27. API privée L'API est disponible pour un usage interne ou pour des partenaires. Elle est utilisée dans un cadre légal très précis.
28. Chaîne de valeur Les assets ne peuvent pas forcément sortir de l'entreprise Les développeurs sont souvent des employés ou des partenaires sous contrat Les applications sont variées, de même que leur promotion et la distribution
29. Usages de l'API Création efficace d'application publique/mobile Support de partenariats Création d'applications internes
30. Risques Ne pas limiter la compréhension possible de votre API à ceux qui l'ont créée Assurer l'opérationnel : votre API doit donner confiance Evangélisez et marketez votre API en interne comme en externe !
31. Passage public<->privé On ne sait pas comment l'usage de l'API va évoluer Une API développée en interne peut s'ouvrir vers le public Une API publique peut servir de référence et l'ajout de contenus et de services peut la rendre en partie privée
32. Les business models des APIs
33. Quatre grandes catégories... Free Les développeurs paient Les développeurs sont payés Revenus indirects
34. ...et énormément de ramifications !
35. crédits : "APIs : a Strategy Guide"
36. Stratégie produit Il est important de se poser les questions suivantes : Qui va utiliser l'API ? Quels assets ? Qui doit avoir accès à quoi ? Quel type d'application peut-être construit avec cette API ? Qu'est ce qui va motiver les développeurs à utiliser cette API ? Comment toutes les parties vont-elles s'y retrouver ? Comment l'audience va-t-elle découvrir ces applications ?
37. Sponsor business Une API ne doit pas être un délire de geek ! Un partenaire business permet : la pérénnisation d'un projet technique le développement de métriques pertinentes dans l'évaluation de l'intérêt pour l'entreprise de pousser avec les bons KPIs le projet en interne afin d'acquérir des ressources
38. Mise en place de l'équipe Vous aurez besoin : d'un évangéliste (sert aussi parfois de community manager) d'un product manager d'ingénieurs de quelqu'un pour s'occuper de l'assurance qualité d'un peu de marketing d'un peu de légal
39. Les principes-clés dans le design d'API designer vos APIs pour des audiences spécifiques considérations techniques logicielles considérations techniques matérielles
40. Des APIs pour des audiences spécifiques Qui souhaitez-vous adresser en premier ? des développeurs ? des utilisateurs finaux ?
41. L'important pour des développeurs Quelle plate-forme technologique ? SOAP ou REST ? XML ou JSON ? OAuth ou autre chose ? cryptage X.509 ou autre chose ? Le tryptique recommandé à priori : REST + JSON + OAuth (mais ce n'est pas obligatoire)
42. L'important pour des utilisateurs finaux API orientée vers l'expérience utilisateur
43. Différentiez vos APIs Pourquoi un développeur utiliserait-il plutôt votre API que celle de vos concurrents ? du contenu unique, plus complet et de meilleur qualité meilleur support et un sign-in plus simple ? votre API est plus robuste, sûre, rapide (voire cool ?) vos CGU sont plus developer-friendly Mettez en avant les avantages de vos APIs. Différentiez-vous en terme d'offre ou d'incentive. Des appels gratuits et ensuite il faut payer ?
44. Faites simple ! Dans la compréhension, l'essai et l'usage API privée : mettez en avant un use case avec de la valeur API publique : offrez un certain niveau d'accès gratuitement
45. Considérations techniques pour une API : pensez RESTful les URI comptent les paramètres sont importants les formats de données sont importants les codes de retour sont importants tout le reste doit être caché établissez une convention claire de versionning
46. Règles pour les URIs noms au pluriel pour les collections nom au singulier suivi de l'identifiant pour accéder à un objet vous pouvez inclure le versionning dans le chemin d'accès pour les collections, des paramètres de requête sont possibles
47. Les verbes HTTP GET pour lire PUT pour ajouter POST pour mettre à jour DELETE pour supprimer
48. XML vs JSON XML : format standard de REST à l'origine Permet de décrire des data sets complexes, de les valider à travers des technologies standard. JSON est par contre beaucoup plus simple et moins verbeux.
49. Versionning et design d'API Version ou pas ? Il faut changer le contrat le moins souvent possible Faites tout pour ne pas incrémenter le numéro de version Des URIs sans version définissent la dernière version de l'API Sinon vos développeurs partiront.
50. Impact du versionning Que faire des anciennes versions ? Qu'arrive-t-il aux applications supportant les anciennes versions ? Combien de temps les anciennes versions resteront supportées ? Ayez une politique de versionning claire !
51. Médiation et API versionless La médiation permet de gérer les changements de version en faisant les transitions entre les contrats Être versionless => réflexions plus forte up-front pour une généricité accrue
52. Considérations techniques matérielles Principe Datacenter ou Cloud ? “Designez pour l'audience rêvée, mais provisionnez pour la charge attendue”
53. Considérations techniques matérielles Comment vaincre la latence ? Sauf si votre code est long/lent, la latence vient surtout de la distance entre le serveur et le consommateur Les Content Delivery Networks (CDNs) et le caching (à tous les niveaux et correctement !) sont des réponses
54. Sécurité et gestion d'utilisateurs sécuriser quoi ? à quel prix ? quel impact sur les performances de votre API ? identification des utiliateurs ou seulement de l'application ?
55. Techniques de base de sécurisation Identification : qui fait la requête ? Authentification : cette personne est-il vraiment celle qu'elle prétend être ? Autorisation : cette personne est-elle autorisée à faire ce qu'elle essaie de faire ? Vous n'aurez pas forcément besoin d'implémenter ces trois éléments.
56. Gestion des utilisateurs Vous aurez besoin d'une interface pour gérer les utilisateurs. Et une pour qu'ils puissent gérer leurs informations. Quel niveau d'information et de spécificité en fonction de leur SLA ? Devez-vous tout faire tout seul ? La vraie question : de quelle intégration avec vos process business avez-vous besoin ?
57. Identification Il faut tout d'abord déterminer l'application qui utilise votre API => API key Ne sert pas à la sécurité !
58. API key Obtenue auprès du fournisseur Permet aussi de collecter de l'information sur les usages de votre API Pour certaines APIs cela suffit parfois Moyen d'arrêter l'usage d'une application vérolée ou mal codée Besoin aussi de demander l'accord de l'utilisateur pour l'accès aux données
59. Authentification Login/Password Solution classique d'identification Si les informations passent par de l'HTTP Basic authentication, ne pas oublier le support d'SSL ! Obstacle : stockage sécuristé du password Stockage sous forme encryptée dans une base de données, voire un credential mapper
60. Gestion basée sur des sessions Appel à une fonction login avec login+password Renvoi d'une clé de session unique incluse dans chaque appel Appel à logout à la fin Implémentations originelles complexes à base de cookie Marche bien pour du web-based, sinon non.
61. Autres méthodes d'authentification En dehors de l'HTTP il existe par exemple : SAML certificats X.509 two-way SSL => Basé sur la gestion de paires de clés, WS-Security et SOAP notamment. Pour du B2B entre grandes entreprises ou des utilisateurs de SOAP.
62. Authentification et autorisation OAuth Protocole ouvert d'authentification sécurisé d'API Technologie la plus répandue sur le web Basé sur des token d'authentification du triplet application/API/utilisateur Évite de faire transiter des login/password ou de faire rentrer plusieurs fois un password Notion équivalent aux API key dans OAuth Les tokens doivent être protégés de manière efficace !
63. Fortification avec SSL Devenu indispensable pour assurer la sécurité des données des utilisateurs Lourd à la connexion, léger à l'utilisation Nécessaire pour les données sensibles ou quand le mécanisme d'authentification le demande
64. Encryption Indispensable si des données sensibles sont échangées. Attention aux règles nationales sur la protection des données SSL reste une solution très répandue A noter que XML Encryption peut aussi être utilisé, mais est plus lourd
65. Détection de menace et prévention Dès que votre API va être disponible sur internet, elle peut devenir la cible d'attaques. Injection SQL Attaques XML et JSON Envisagez d'utiliser le masquage de données en fonction des niveaux d'accréditation des utilisateurs
66. Aspects légaux concernant les APIs Deux grandes questions : Pouvez vous redistribuer les données que vous fournissez ? => Relation contractuelle entre vous et les autres. Quels sont les droits que vous voulez donner aux consommateurs ? => Dépend des contrats directs que vous avez avec partenaires et aux conditions d'utilisation pour le public Un lancement "soft" ou une beta privée peuvent permettre de tester différents scénarios.
67. Aspects légaux concernant les APIs Quels sont les différents accès possibles aux APIs et à quoi donnent-ils droit ? Contraintes fortes sur les APIs pour gérer toutes ces nuances de droit d'accès, d'utilisation, de redistribution, etc.
68. Système de gestion de droits Il faut pouvoir tagger ses contenus avant de gérer leur distribution. Un filtrage peut se faire au niveau : de la requête du groupe de contenu d'un contenu spécifique de l'utilisateur des permissions
69. Contrat d'utilisation Attention à la façon dont votre marque est utilisée. Destiné aux utilisateurs finaux, mais aussi aux développeurs. Exemples : Twitter ou validation de CGU
70. Gestion et rétention des données privées Annoncez l'usage fait des données privées Il est important de réfléchir à la rétention des données. Exemples : Facebook ou NPR
71. Attribution du contenu et "branding" Permettez aux développeurs de brander vos contenus dans leurs applications (logos, symboles de copyright, etc.)
72. Du mauvais usage de vos APIs Quand c'est le cas, voici des questions à se poser : Qui doit évaluer le mauvais usage ? Qui doit contacter le consommateur de l'API ? Si le problème persiste, quelles sont les implications légales ? Sous quelles conditions, quand et comment doit-on supprimer l'accès à l'API ?
73. Gérer et rendre disponible une API Vous pouvez avoir le meilleur design pour votre API, mais c'est inutile si elle n'est pas accessible. Ce n'est pas qu'une question technique : il faut aussi un support efficace et une bonne façon de communiquer.
74. Gestion opérationnelle de votre API Vous devez pouvoir répondre aux questions suivantes : Quels sont les SLAs que vous fournissez à vos différents types d'utilisateurs ? Quel temps de réponse pour le support ? Avez-vous un système de monitoring ? Qui les clients doivent-ils contacter ? Tous de la même manière ? Êtes-vous capable d'avoir du feedback sur vos produits ? Quels sont vos politiques de failover ou de récupération si vos serveurs tombent en panne ? Que se passe-t-il si TechCrunch, FrenchWeb, etc., parlent de vous et font exploser vos visites ?
75. Informations en libre accès Ayez une page de statut de votre API Utilisez les sites de microblogging comme Twitter
76. Problématiques opérationnelles Proposez des environnements de test à vos utilisateurs Évaluez l'impact d'un utilisateur (API/Infra) Le SLA peut varier en fonction du prix payé Attention à vos dépendances dans la définition du SLA
77. Gestion des bugs, support et monitoring Cela arrive, même aux meilleurs, soyez donc prêts ! Ayez un monitoring proactif Que les responsables soient notifiés si quelque chose arrive Forum, Bug Tracker, réseaux sociaux, hotline, e-mails Utilisez les moyens adaptés à vos populations d'utilisateurs Priorisez les requêtes de support (criticité/SLA)
78. Documentez votre API Elle se doit d'être simple à utiliser, mais auss très bien documentée Est-ce que vos développeurs disposent d'outils pour les aider dans leurs développements ?
79. Fournissez à vos utilisateurs de quoi connaître : Les codes d'erreur Les endroits où trouver l'information de statut de votre API Comment fournir du feedback
80. La documentation devra d'ailleurs être de deux types : Documentation de référence Documenation de démarrage : tutoriel, quick start, etc. Et la documentation peut inclure des informations d'architecture : modèle d'authentification principe d'attribution et de branding condition d'utilisation etc.
81. Approches de gestion de trafic Comment gérer un usage intensif, voire le flooding de vos APIs ? quota throttling arrêt du trafic venant de clients buggés ou d'attaquants
82. Gestion du trafic D'autres raisons peuvent apparaître pour mettre en place une gestion de trafic : vente d'accès premium aux API facturer ses utilisateurs pour des usages exceptionnels modèle à quota d'usage décourager l'usage abusif d'une API suivre l'usage des consommateurs de données monitoring des usages au sein de groupes
83. Gestion par quota Habituellement : nombre d'appels à l'API sur une certaine période Attaché à une application ou à un utilisateur Exemple : Twitter limite à 150 appels à son API par heure Une implémentation efficace est plus qu'un simple décompte d'appels... Quel quota pour quel SLA ? Sur quelle période ? Comment gérer les consommations hors quota ?
84. Throttling On ne limite pas l'usage, mais on le ralentit Plus user-friendly , on n'empêche pas l'usage par des codes d'erreur brutaux Nettement plus complexes à implémenter, par exemple avec des systèmes de queuing
85. Gérer les pics de charge (et pouvoir les arrêter) Permet d'éviter les attaques de type DOS Permet d'éviter que tous les "bons" utilisateurs soient impactés par un "mauvais" Permet d'éviter que le système ne tombe
86. Gestion de la scalabilité Différentes technologies existent : Load Balancer Serveurs dédiés pour le contenu statique Cache de données Serveur DNS CDN Gateway pour API (gère la sécurité, le logging, load balancing, caching, etc.)
87. Mesurer le succès de votre API Il est difficile d'améliorer ce que vous ne mesurez pas Définissez au plus tôt le top 3 des métriques à suivre Comparez avec des projections réalistes Ayez des dashboard réguliers (hebdomadaires)
88. Traquez l'usage de vos APIs Qu'est ce qui a été consulté et par qui ? Infos fournies et pour quelle requête ? Que voit l'utilisateurs ? Qu'en fait-il ? Attention : traquer les requêtes et les réponses n'informe pas sur la valeur générée et/ou perçue.
89. Comprendre le flow d'usage et efficacité Il est important de savoir comment l'utilisateur enchaîne les appels à votre API et comment il enchaîne les contenus fournis. Ceci est complexe si vous n'avez pas de login où si les terminaux changent au cours de l'utilisation. Il est aussi important de se rendre compte de l'usage d'API pour des opérations complexes mais d'apparence simple.
90. Performance de votre API Comment est ce que l'usage de votre API mappe le(s) business model(s) mis en place ? Est-ce que le service est perçu comme bon ? Quelle est la latence perçue atomiquement et globalement ? Quelle est la fréquence des bugs ? Assurez-vous le SLA annoncé ? Comment votre API impacte-t-elle vos autres outils web ? De quelles informations avez-vous besoin pour prendre des décisions stratégique ? Que vous coûtent les données fournies et l'infrastructure sous-jacente à ce service ?
91. Comment encourager l'adoption de votre APIs ? Créez un programme pour les développeurs Affichez votre produit et pourquoi ils devraient l'utiliser Rendez-le simple et rapide à utiliser et accessible (votre produit et vous !) Affichez vos conditions d'usages et les bénéfices associés Fournissez du contenu comme des tutoriaux, des screencasts, webinars, quickstarts, outils de développement, chez vous, mais aussi là où les développeurs se trouvent Evangélisez vos cibles Mettez en avant les cas d'usage Permettez à la communauté de grandir, d'avoir du support et de collaborer
92. Développez un portail pour développeurs Facebook et eBay en ont des bien ! Ils fournissent : De l'information par rapport à l'offre De la documentation Un bac à sable pour tester l'API Des galleries d'applications Des moyens de contact Les informations pour faire du business
93. Les choses à faire Animez votre site web, votre présence sociale Visez les "alpha-geeks" Faites vivre votre communauté, mettez en avant les développeurs et faites-les entrer en relation Cherchez les leaders d'opinion pour les gagner à votre cause Connectez-vous à d'autres communautés
94. Les choses à ne pas faire Être comme les autres Rendre l'inscription compliquée Les discours trop commerciaux Rester concentré sur vous-même Avoir un mauvais community manager Soyez concentrés sur vos cibles : il est compliqué de contenter tout le monde.
95. Merci Webinars : Comprendre les enjeux techniques du SaaS : 14 et 28 février Adopter les bons processus de développement pour le SaaS : 15 février et 1er mars SaaS : Comment bien mettre en place son Business Model : 12 et 20 mars blog.sysfera.com @DavidLoureiroFr
96. Formations : Formation à Git, le gestion de version nouvelle génération : 26-27 février Formation à Jenkins, la réussite par l'intégration continue : 26-27 mars Et d'autres formations sur C++, Python, les systèmes distribués, le Cloud et le calcul parallèle ! Je souhaiterais remercier Daniel Jacobson, Greg Brail et Dan Woods, dont le livre "API : a Strategy Guide" a été inestimable pour la préparation de cette présentation.