Eric Wahlforss est le co-fondateur de la start-up berlinoise SoundCloud.
SoundCloud est une solution pour résoudre les difficultés des artistes, labels et autres professionnels de la musique à recevoir, envoyer et distribuer leur musique, de manière privé ou publique.
Autrement dit, il s’agit du Flickr de la musique.
SoundCloud parie énormément sur son API web ouverte comme moyen de devenir la plateforme d’échange musicale du web.
Je l’avoue, j’ai donc d’abord eu l’idée d’interviewer Eric pour enrichir la stratégie d’API Web d’un client en stratégie web. Mais impossible de garder ça pour moi :-)
Cette interview inédite nous permet de saisir l’état d’esprit d’une jeune entreprise qui cherche à rendre leader son API, conçue dans les règles de l’art.
Julien : Vous semblez avoir tout prévu pour votre API : oAuth, authentification de base dans le bac à sable [sandbox], une console de test super-cool, etc. Aviez-vous vraiment un plan parfait ?
Eric : Notre API a été une pierre angulaire importante de notre plateforme dès le démarrage, donc oui, nous avions des plans plutôt ambitieux pour notre API dès le début. Mais bien s√ªr, les premières versions étaient loin d’être parfaites, et beaucoup de choses n’étaient pas en place ou même fonctionnelles.
Notre première version de l’API est sortie au printemps 2008 au cours de notre beta privée, et nous avons fait des itérations continues depuis. Nous continuons de sortir de petites (et de plus grandes) mises à jour sur un rythme presque hebdomadaire.
Construire une API par étape
Julien : Quelles sont les erreurs que vous avez faites en implémentant votre API, que vous ne ferez plus, mais que vous voyez les autres faire ?
Eric : Nous avons démarré tôt avec oAuth (2007), et malgré que cela soit une excellente technologie, de plus en plus utilisée, nous avons perdu beaucoup de temps au début à cause de bugs et de spécifications peu claires.
Malgré cela, si je devais construire un API aujourd’hui, je n’hésiterais pas à utiliser oAuth pour la couche d’authentification. Je ne peux pas vraiment comprendre le besoin d’inventer son propre système avec des clefs personnalisées, ou ce genre de chose que je vois certaines startups faire. La chose la plus importante que oAuth fait, c’est de cacher la complexité pour l’utilisateur final : aucun partage de clés ou mots de passe spéciaux.
Par ailleurs, certaines startups ne voit pas la puissance qu’il y a dans l’itération et les améliorations par petites étapes de leur API, et essayent de concevoir quelque chose de parfait dès le premier jour.
Le problème, bien s√ªr, c’est qu’il ne vous est pas possible de prévoir toutes les différentes façons dont votre API sera utilisée. Il est donc beaucoup plus efficient en terme de ressources de simplement développer de nouvelles extensions basées sur les demandes de fonctionnalités des développeurs (c’est principalement notre façon de faire actuellement).
Une autre chose est la maxime commune qui dit « mangez votre propre API » [de l'expression américaine to eat his own dog food], qui implique que vous devriez l’utiliser pour votre propre application.
Nous l’avons fait au début, mais il s’avère que nos besoins pour notre API privée (soundcloud.com) étaient très différents des besoins publiques, et spécialement au fur et à mesure que la plate-forme évoluait.
Et donc rester compatible et utiliser notre propre API malgré tout a commencé a nous ralentir. Et après quelques mois cela ne semblait plus aller de soi. Il nous fallait donc briser cette habitude et créer notre propre API privée pour les choses que nous faisons sur le site.
Je ne recommanderais plus la stratégie « mangez votre propre API » dorénavant. C’est beaucoup trop « idéologique » et ne vous aidera pas à lancer votre projet.
Julien : Si je comprends bien, vous avez ajouté vos propres caractéristiques privées seulement quand vous avez senti que votre API publique était une contrainte pour la webapp SoundCloud elle-même.
Quelque chose que nous voyons beaucoup, y compris aujourd’hui, est exactement à l’opposé : une API publique extraite d’une application déjà construite. Les fonctions offertes au public sont choisies dans un ensemble privé plus grand.
Dans tous les cas, comment décide-t-on de ce qui doit être public, ce qui devrait être privé? Que dirais-tu à quelqu’un en charge d’une application web à ce sujet?
Eric : En réalité, je le ferais un peu différemment de la manière dont nous l’avons fait — et donc plutôt comme vous l’avez mentionné, je créerais simplement en premier une API privée et ensuite je mettrais en place un namespace totalement distincts pour l’API publique.
L’application web devrait avoir sa propre API privée. Et l’API publique devraient être conçue pour des gens qui construisent des choses au-dessus de la plate-forme (ce qui est un besoin tout à fait différent si cela doit être généralisé)
Séduire les utilisateurs de l’API, alias « les devs »
Julien : Est-il facile de recueillir les réactions des utilisateurs de l’API, c’est à dire les développeurs ?
Eric : La plus grande difficulté a peut-être été de pousser les développeurs à créer réellement quelque chose au-dessus de notre plate-forme. Je pense que maintenant nous sommes enfin au-delà de cette étape — les gens se rendent compte à quel point la plate-forme est utile et puissante, et nous avons de nombreux projets passionnant en cours.
Nous avons été très réceptifs aux retours à tous les niveaux, pas seulement pour notre API. Donc, nous essayons toujours d’écouter attentivement et de s’adapter aussi vite que nous le pouvons aux besoins des développeurs, dès que nous voyons plus d’une personne demander quelque chose.
Bien s√ªr au fur et à mesure que la plate-forme se développe, nous perdons un peu de notre agilité, car nous devons nous assurer de rester en rétro-compatible et ainsi de suite.
Julien : Cela m’amène à la question de la gestion des versions !
Alex Payne de Twitter m’a dit que c’était une de leur principale erreur avec leur API, ne pas avoir versionné depuis le départ.
Avez-vous réussi cela dès le début? Quelle est votre approche du problème des versions face à la rapidité de l’évolution de votre API?
Eric : Jusqu’à présent, les ressources de base ont été relativement stables, nous n’avons pas vraiment vu la nécessité de supprimer quoi que ce soit de l’API, mais plutôt de lui ajouter de nouveaux attributs et ressources.
Notre plan a été depuis longtemps de gérer les versions, avec le point d’entrée racine étant systématiquement un alias vers la dernière version. Alors, oui, nous finirons par versionner l’API. Mais nous n’avons toujours pas atteint /1.0/ :)
Julien : Y a-t-il des moments où vous avez senti que le paradigme RESTful constituait une limitation (face à des choix plus complexes/complets comme SOAP) ?
Eric : Parfois nous avons l’impression que nous avons à faire entrer au chausse-pied dans un paradigme REST quelque chose qui ressemble davantage à un appel de méthode.
Mais généralement la conception orientée ressource fonctionne vraiment bien. La majeur partie de ce que nous faisons via l’API est du CRUD [Create, Read, Update and Delete], après tout.
Parfois, nous avons sacrifiée une partie de notre approche REST pour plus de commodité et pour limiter la quantité d’appels faisant des allers et retours dans les tuyaux.
Julien : Vous semblez essayer avec force de réduire les obstacles à l’adoption de l’API. Votre console par exemple, est vraiment, vraiment très bien. Elle a même une authentification de base pour effectuer des tests sans oAuth.
A votre avis et avec l’expérience, quels sont les principales barrières techniques qui doivent être supprimées pour une large adoption par les développeurs de l’API ?
Eric : Nous avons vu que oAuth est la plus grande barrière dans notre cas. Et donc avoir des wrappers de haute qualité pour l’API et une documentation complète disponibles pour tous les languages importants est la clef pour abaisser les barrières.
Je veux vraiment que les utilisateurs puissent écrire [en Ruby] » gem soundcloud; Track.new(:title=>’my track’) » [pour créer une nouvelle piste sur SoundCloud]… Cela doit être aussi simple que ça, vraiment.
Julien : Quelle est l’utilisation la plus surprenante de l’API, l’utilisation qui vous a fait dire : « Je n’aurais jamais pensé à ça! »
Eric : Et bien, nous avons eu une application assez cool appelée SoundDrop, réalisée au cours du Musichackday de Londres, cet été.
Il s’agit essentiellement d’un service qui prend ce qui est dans votre DropBox SoundCloud et génère un mix personnalisé à partir de ça, en mettant en évidence les parties les plus « intéressantes » des pistes, en utilisant les APIS Echonest et SoundCloud. C’est assez cool! Voici une vidéo de SoundDrop sur notre blog.
Autre chose créée au cours du Hackday a été citysounds.fm, qui vous permet d’écouter la musique de milliers de villes à travers le monde (et en quasi-temps réel, car le site scanne les derniers ajouts). Cela leur a pris 15 heures a construire et le site a reçu plus de 100.000 visiteurs uniques au cours des premières semaines d’existence !
Durant le second Musichackday à Berlin, j’ai aussi aidé à hacker sur le projet TracksOnMaps.
Le point de basculement…
Julien : Quel a été le point de basculement en terme de développeurs qui utilisent effectivement l’API pour construire quelque chose?
Eric : Je crois que le point de basculement a été récemment, une fois que nous avons intégré dans notre équipe un responsable partenariat à temps plein sur l’API. Il a parlé de façon très systématique à toute l’industrie des logiciels de musique et autres entreprises/sites sur la mise en place d’intégrations — et beaucoup ont répondus positivement.
En termes de choses implémentées, je pense que nous n’avons toujours pas vu le point de basculement… mais je peux vous promettre que c’est pour bientôt…
Julien : Venez-vous de trouver la formule magique pour inciter les développeurs à s’investir sur l’API? :-)
Eric : Les Musichackdays ont également énormément contribué à donner l’envie aux développeurs de construire des choses, et ils font donc clairement partie de la formule.
Julien Dorra est coach en stratégie web.
(photo CC-by de pellesten)
A lire également :
