La fin d’année a vu se tenir un salon en plein essor, tout près des Champs Elysées, dont le nom annonce la teneur : API Days.
Plus de 40 speakers dont beaucoup de renommée mondiale, certains représentants de grosses sociétés françaises… pour parler Web API et écosystème associé. Tous les sujets n’étaient pas forcément 100% techniques comme vous allez le voir après, mais tous 100% instructifs.
Réintroduisons le contexte. API, tout le monde n’a peut être pas en tête la même définition. Le sujet évoqué aux API Days était celui des services web légers qui fleurissent de toutes parts, boostés par l’essor de la mobilité, mais pas que… Ces services, qualifiés de Web API, ou de façon plus courte API, parfois aussi de “services REST”, et là, je vous renvoie à cet article [/2013/09/17/le-buzzword-du-jour-rest/], sont maintenant la forme privilégiée pour exposer des données et services.
Les deux jours de conférence des API Days de Paris se sont donc déroulés tout près des Champs Elysées [http://apidays.io/#pratical]. Répartis sur 2 salles, un choix devait donc s’opérer parmi les talks proposés. C’est toujours frustrant mais c’est le jeu.
Différents sujets ont été couverts : des réflexions sur l’avenir des API [Telephones, Mechanical Turks, and the Future of APIs – M. Amundsen – Layer7], présentation de solutions promettant de simplifier certains aspects techniques [Shipping code in a service oriented world – Joffrey Fuhrer – Docker.io], présentation de concepts avancés issus de la recherche [Transactional Internet Service Composition – Maude Manouvrier – Dauphine LAMSADE], des retours d’expérience chargés de pragmatisme [From a Monolithic to a Distributed Architecture – Renaud Visage – Eventbrite, Building an API Platform – Laurent Benveniste – Orange], …
Essayons de résumer en quelques sections la teneur des échanges.
L’essor des API
Le nombre d’API augmente fortement. Le site ProgrammableWeb [http://www.programmableweb.com/] en recense plus de 10 000 maintenant. Il ne s’agit donc pas uniquement d’un effet de mode : l’intérêt de ce type d’exposition de la donnée et des services est reconnu. Quiconque souhaite s’engager dans un projet de cette nature considère maintenant d’abord les API web avant tout autre mode d’exposition, dont les services web de type SOAP. Mais si cet essor est une bonne nouvelle, un certain nombre de points restent non couverts et c’est maintenant sur ceux-ci que se portent les efforts des évangélistes. On pourra citer le principal : l’utilisation des liens hypermédias dans les API, mais aussi la capacité à intégrer les évolutions sans recours au versioning des API, l’orchestration des API…
Autre corollaire à ce fort développement : la réinvention perpétuelle de la roue, ou l’absence de mutualisation dans la modélisation. Beaucoup d’API concernent des besoins identiques et pour autant ne partagent pas d’interfaces et de formats communs. Cet écueil est aussi un frein à la capacité d’interopérabilité et trouve des réponses sous forme d’initiatives comme API Commons [http://apicommons.org/], sous l’impulsion de Kin Lane et avec la bénédiction de la communauté. Dans la même idée, l’utilisation de formats de représentation standardisés commence à gagner en visibilité. Aussi, des formats comme JSON API, présenté par Steve Klabnik, proposent de structurer les représentations et de donner un cadre aux définitions des interactions possibles. Il en existe d’autres dont le périmètre n’est pas strictement identique, mais dont la direction est sensiblement la même : HAL, JSON-LD, Collection+JSON, Siren…
Toujours plus de productivité
Pour répondre aux exigences toujours plus fortes de time to market, sans sacrifier la qualité, la communauté produit différentes solutions. C’est ainsi que des initiatives comme Docker.io permettent de proposer un nouveau niveau d’abstraction pour le déploiement des applications. Toujours dans l’idée de simplifier la création d’API, API Spark [https://apispark.com], de RESTlet, permet la création, l’hébergement d’API en quelques minutes. La version beta publique a par ailleurs été lancée pendant les API Days. Cette plate-forme permet la création d’API, la gestion de la documentation, du versioning, la fourniture de statistiques d’utilisation… de façon intégrée.
Savoir avancer progressivement, pragmatiquement
C’est ainsi que plusieurs acteurs présents [Orange, Eventbrite…] ont décrit comment ils ont procédé pour leur démarche d’intégration d’API web. Ils ont aussi détaillé quelles incidences cela avait eu sur l’entreprise elle-même, au delà même du département informatique (chez Orange, les API sont au cœur d’une stratégie globale, poussée par la Direction). L’apprentissage des uns et des autres sur le terrain permet de consolider les retours d’expérience et de faciliter l’accession aux API aux futurs arrivants. Les bonnes pratiques sont partagées [API platform and mobile – Applidium, The Art of Selling APIs – Mashape, …] et facilitent le travail de convergence. Si vous avez un projet de création d’API, vous n’atteindrez probablement pas un niveau d’excellence au premier coup, mais qu’importe : apprenez des succès et erreurs des autres et lancez-vous.
La dimension humaine
Autre leitmotiv présent pendant ces deux jours : l’Humain. Créer une API, c’est s’adresser à un public d’utilisateurs : les développeurs. On crée une API dans l’objectif qu’elle soit utilisée et son adoption dépendra d’un facteur important, au delà du service ou de la donnée exposée : son ergonomie générale. Cela peut se résumer avec un terme proposé par Dan Feist de Mulesoft : APX. l’APX est aux API ce que l’UX est aux UI. L’expérience utilisateur doit aussi être un élément d’attention lors de la conception d’une API ! Pour cela, plusieurs points sont importants : définir une interface claire, homogène ; fournir une documentation avec l’API, la plus didactique possible et accompagnée de tous les outils utiles (documentation des représentations, possibilités d’interaction, …, mise à disposition d’une sandbox pour tester l’API, support par réseaux sociaux, …); être à l’écoute des utilisateurs et répondre aux besoins qu’ils remontent. Cette attention est d’autant plus importante que si votre API n’est pas simple à utiliser, compte tenu du nombre impressionnant d’alternatives, les développeurs iront à la concurrence si le ticket d’entrée est jugé trop élevé chez vous.
Le futur
Comme évoqué, le futur concerne les aspects toujours rarement intégrés comme les relations hypermedias, l’utilisation de medias types adaptés, si ce n’est standardisés, le recours à des patterns fonctionnels communs, mais aussi à des sujets techniques complexes, dont certains étaient évoqués, comme la capacité à orchestrer les services, à assurer des comportements transactionnels (via des mécanismes de compensation), comme évoqué lors de la présentation des activités de recherche du LAMSADE à Paris Dauphine, mais aussi évoqués par Ken Worwizewicz [Rackspace, “The future of APIs is orchestration”].
Pour conclure
Les API Days 2013 ont démontré l’intérêt croissant pour les API Web : de nombreux participants étaient présents pour venir écouter des speakers de qualité, dont certaines figures emblématiques. Beaucoup d’information a été diffusée pendant ces deux jours, des concepts théoriques aux recommandations issues des retours d’expérience, en passant par de nouveaux outils… Vous pourrez retrouver (prochainement) les talks sur Youtube à cette adresse : http://www.youtube.com/user/apidays
Gageons maintenant que l’an prochain les graines semées cette année à travers les présentations aient eu le temps de germer et que les sujets évoqués aux API Days 2014 soient encore plus intéressants qu’ils ne l’ont déjà été en cette fin d’année 2013. Stay tuned!
