Un marché de plusieurs milliards de dollars (pareil en euro).
…. Zzzzz…………Zzzzz………….
Des applications dans votre poche sur votre téléphone intelligent connectées à des services… Une superbe application d’enterprise où l’équipe du backoffice a intégré le calcul de la Value At Risk avec un moteur de collatéral… Et un site basé sur les données de ZapTravel, où tu peux trouver les meilleurs packages pour aller faire du surf ou de la planche à voile, ou un petit weekend en amoureux… et une application sur portable spéciale « Saint Valentin » avec des deals hotel + avion + concert romantique à Palavas-les-flots… merde Palavas c’est pas Romantique…. BUUUUUGGG !!!
Le réveil sonne et je te réveille, tu me bouscules, et on parle API Web au petit-déjeuner.
Vous avez vu toutes ces applications et ces sites webs qui proposent une API Web ? Github ? Twitter ? Google Maps ? Et Facebook qui partage aussi tes vieux messages privés ?
Une API (Application Programming Interface) est une porte d’entrée technique vers votre système d’information. Une API Web est donc une porte d’entrée exposée comme un serveur Web, avec laquelle vous pouvez communiquer. Si vous utilisez Twitter à partir de votre téléphone portable, sachez qu’il y a de fortes chances que le client Twitter installé utilise l’API technique de Twitter, dev.twitter.com.
En général, il s’agit d’une interface documentée, que vous pouvez utiliser après vous êtes inscrit. L’API sociale de Facebook ou de Twitter utilisent OpenID, un standard d’authentification décentralisé OpenID. Après s’être inscrit sur le site, une clé privée vous donne alors accès à une partie de la plateforme technique du service Web. Récemment, j’ai utilisé l’API Web de Mailchimp pour gérer des listes de diffusion, l’API sociale de Facebook pour analyser des profils et l’API Twitter pour suivre des hashtags. Cela ne demande pas un effort de programmation immense, et c’est un standard de fait.
Les API Web deviennent aujourd’hui de plus en plus importantes. Un service comme Twitter n’aurait pas eu autant de succès s’il n’était resté qu’un système fermé ou purement web. Le site ProgrammableWeb recense plus de 7400 APIs, dans des domaines aussi divers que le tourisme, les réseaux sociaux, les photos, les achats en ligne, la science, la téléphonie, la météo, etc. Il est possible d’utiliser un système capable de vous fournir des milliers de données et des milliers de service.
Une application sans API a-t-elle autant de valeur que lorsqu’elle utilise différents services webs ? Dans un article publié en août 2012 sur pandodaily, Steven Millot parle d’une API Economy, plutôt que d’une AppEconomy.
Today, 77 percent of the current top-50 free and top-50 paid apps connect to backend services of some kind (including game social networks), and only 23 percent were completely stand alone (never calling home to some kind of backend).
Prenez votre service et imaginez avec un peu d’efforts ce qu’il serait possible de faire pour exposer librement vos données et vos fonctions. Imaginons que vous ayez développé un superbe pricer en Java, ou une application de calcul de couverture d’assurance… ne serait-il pas intéressant d’ouvrir vos services dans votre système d’information ? Après tout, si vous travaillez dans la même entreprise que des clients potentiels, pourquoi pas ?
Si vous êtes dans le monde des startups, ne pas prendre en compte les API Web existantes est une erreur stratégique. Ne pas construire soit-même une API peut se comprendre. Pour ce qui est de prendre en compte l’existant, vous n’avez peut-être pas besoin de Twitter, mais de Google Maps par exemple. Une architecture complète dans le Web, particulièrement dans le monde des startups et des nouveaux services, se doit de regarder les API Webs existantes. Il y a tellement de services, qu’il serait dommage de réinventer la roue. Le premier qui me vient en tête : l’envoi d’email. Pour ZapTravel par exemple, nous utilisons 2 web services : MailJet et MailChimp. Le premier pour les emails transactionnels, le deuxième pour les listes de diffusion et le marketing.
Ne pas construire une API peut aussi se comprendre. Vous pouvez faire le choix de ne construire « que » votre site web, censé représenté votre service et votre proposition de valeur. Vous venez d’inventer un superbe système de réservation de collocation de voiture pour végétarien ? Pourquoi ne pas exposer une API et permettre ainsi à différents partenaires d’utiliser votre service ? Des solutions comme StackMob ou Parse permettent de construire la partie Backend, de pousser les données mobiles vers le cloud, de faire de la notification et toute la partie serveur utilisée par une application mobile.
Au passage, pour ceux qui en veulent, il y a un eco-système en demande, qui peine à trouver de bons produits complets. Tu vois, entre nous, l’avenir c’est pas trop les serveurs JEE, mais plutôt les serveurs EBM (Enterprise Backend for Mobile). Je parle d’un marché assez important, utilisé par le plus grand nombre. Apple a reversé par exemple 5.5 milliards USD fin juin (source ici) aux éditeurs d’application hébergées sur l’AppStore.
En France, Webshell est une startup actuellement à l’incubateur Le Camping, qui développe un système assez génial pour simplifier la mise en place des API dans votre système. Il y a plus de 40 APIs supportées, environ 400 développeurs beta-testeurs en ce moment (source). Avec quelques lignes de Webshell, une page Web et une clé, vous pouvez ainsi créer un mashup très facilement pour votre site.
Aux USA, un service comme 3Scale ou Mashery (utilisé par Klout permettent de déployer, gérer les versions, la facturation et l’utilisation d’une API sur votre plateforme. Apigee s’adresse au monde des entreprises afin de les aider à externaliser justement leurs services et leurs données, via des API Webs.
Ce qui est intéressant dans tout ceci, c’est la faible place de la technique et des standards… car ils existent déjà. Pas besoin ici de « normalisation » ou de « spécifications » puisqu’une API Web est simplement un service Web, qui expose soit une interface type document, soit une interface type RPC. Ensuite vous pouvez vous faire plaisir avec SOAP-XML, mais la majorité des APIs aujourd’hui sont plus simples. Lorsque je dis que faire simple c’est pas compliqué… Bref si vous regardez un peu sous le capot, vous verrez du HTTP, sur des architectures type REST. Tiens en passant, REST n’est pas un protocole comme je l’ai entendu l’autre jour, mais bien un style d’architecture qui date de 2000.
Alors faut-il mettre des services Webs dans votre SI ou dans votre superbe produit startup ?
Pour ZapTravel, nous avions au départ la vision d’un site pour vous proposer des destinations que les autres n’ont pas sous la forme de package afin de vous aider pour le temps de préparation dont vous ne disposez pas. Or en discutant, plusieurs cafés plus tard (ou Mojito, je sais plus), nous nous sommes aussi rendu compte que la valeur de notre entreprise repose sur les données. Nous avons tout un tas de petits robots qui agrègent des données, et de vrais humains qui font des incantations magiques sur celles-ci pour que cette donnée se transforme en or (pour vous).
Or nous nous sommes dis (enfin surtout moi), que faire une API pour te permettre de taper sur notre base et nos services… ça serait sympa.
Vous pourrez intégrer le système de données de ZapTravel et construire pourquoi pas « Zap Windsurf » avec les 50 meilleures destinations pour aller faire de la planche à voile. Ou pourquoi pas « Zap Budget » avec les meilleurs packages qualité/prix… Ou encore « Zap Party » où vous trouverez des packages pour aller faire la fête de la bière en Allemagne ou la fiesta à Barcelone…
Et que peut-être que Palavas-les-flots est finalement une destination romantique… qui sait ?
Z’en pensez quoi ?
0 no like
Déjà je pense que Plavas n’est pas du tout une destination romantique.
Sinon pour l’ouverture d’un site/service via une API je vais faire une réponse de bon normand que je suis et dire que tout dépend du service proposé.
Si on fait un site d’info, de news etc. je trouve que la mise à dispo d’une api présente peu d’intérêt. Il y a (« normalement ») déjà ce qu’il faut un flux rss, alors autant concentrer son temps à en faire une version mobile sexy.
Si on propose un service e-commerce par exemple, alors là on a tout intérêt à développer une API pour qu’éventuellement des tiers passe par notre service.
C’est une question de contexte quoi.
La vrai question qu’il faudrait se poser aujourd’hui est, à mon avis, faut-il développer le site web qui correspond à l’api ? Je me pose moi même la question sur un projet perso.
Tres bon article sinon, qui est dans l’air du temps, l’API Centric Development (je sais plus ou j’ai vu le terme).
J’ai récemment parlé avec un entrepreneur de la silicone valley qui parié sur l’avenir des sites connectés (branchés à des API ou proposant sa propre API), et que le site non connecté n’avait plus d’avenir. Je pense la même chose aujourd’hui.
Une start-up, qui veut se développer, a tout intérêt à utiliser/proposer des API . C’est un énorme avantage de voir son service foisonner grâce à des développeurs créatifs et talentueux 🙂
Salut,
On s’est fait exactement la même remarque pour Silverpeas même si nous n’avons pas vocation à faire des sites web grand public ;o)
Offrir une API web à base de services REST et fournissant du JSON (linga franca du web) est permet de séparer la vue du reste de l’application (pour du refactoring de code HTML legacy ça aide), de ne pas préjuger des futures IHMs (tablettes, smartphones, …) et facilite la customisation de l’IHM.
Effectivement un effet secondaire est aussi de permettre à nos clients d’intégrer plus facilement Silverpeas dans leur SI mais ce n’est qu’un effet secondaire 😉
Bref pas mal de gains.
Par contre pour une application stateless se pose la question de la gestion de l’authentification et ce n’est pas encore simple avec oauth2 ou dans un contexte d’entreprise …
Perso je trouve ca super toutes ces APIs, je suis pour la diffusion et l’ouverture des services et puis après je me mets à la place de mon boss : quel est le business model lié à ces APIs? comment twitter gagne de l’argent (et est-ce qu’il en gagne)? l’idée est-elle , comme google pour gmap par exemple, de mettre un maxrate et de faire payer quand on le dépasse?
bref, pas du tout des questions techniques ou philosophiques (de ce coté je suis pour) mais « bassement » economique…
Petit plug pour Restlet qui vient de lancer APISpark, une plateforme tout-en-un de création, hébergement, gestion et utilisation d’APIs web, basé sur notre technologie Restlet Framework (utilisable depuis un simple navigateur!).
Plus d’infos sur notre lancement la semaine dernière à GigaOM Mobilize à San Francisco:
http://blog.restlet.com/2012/08/23/launching-apispark-at-gigaom-mobilize-2012/
@gbougeard les API ne sont pas entièrement gratuites (ou alors c’est rare). Elles sont au contraire « scalable ».
Prenons l’exemple de gmap ou Mailchimp : au début, lorsque tu travailles sur une faible volumétrie, c’est effectivement gratuit. Ca permet aux développeurs de se familiariser avec l’API et ça permet de ne pas avoir besoin de « fonds » pour mettre en place les services cibles de ton application alors même que tu n’es pas sûr d’avoir plus de 2 visites par mois.
Quand ton site commence à marcher et que tu dépasses la volumétrie qui te permettait de profiter gratuitement du service, à ce moment tu « passes à la caisse » et dans ce cas c’est plutôt à toi d’avoir identifié au préalable si la valeur ajoutée de ce service était rentable par rapport au gain qu’elle te procure. En effet, à partir du moment où tu t’orientes vers cette solution, tu deviens captif de ton fournisseur sauf… si un concurrent propose exactement les mêmes fonctionnalités avec la même API.
Cependant ne nous leurrons pas, toutes les décisions que nous prenons nous rendent toujours un peu plus captif (choix d’un collaborateur, choix d’une technologie, choix d’un fournisseur), l’important c’est un instant T de s’assurer qu’on a pris la bonne décision, en particulier en considérant les solutions « de repli », c’est-à-dire:
– le jour où Mailchimp augmente ces tarifs, à partir de quel coût je considère que ce service n’est plus rentable?
– si ce n’est plus rentable, est-ce que je peux arrêter complètement l’utilisation de ce service ou bien suis-je obligé de trouver une alternative?
– Si je dois trouver une alternative, quels sont les offres concurentes et leur prix associés (abonnement + changement d’API)? Quel est le coût pour internaliser complètement le service?
Et sinon, ton boss t’a-t’il déjà demandé comment les développeurs de tes frameworks préférés ils gagnent de l’argent? Pour java, pour spring, pour Hibernate, pour jquery… As-tu du remords à utiliser ces technologies?
Quitte à dire une bêtise, il me semble que FB et Twitter utilisent OAuth pour pouvoir accéder à leur API (v1 pour Twitter, v2 pour FB).
Très bon billet sinon avec pas mal de liens intéressants et utiles, toujours agréable de te lire.