La frontière API-interface s’efface un peu plus

Les API ont toujours été au cœur de la vision et du discours d’OpenDataSoft. Alors que nous apportons la touche finale à l’intégration de l’API dans l’interface (et vice versa), c’est l’occasion de faire un point sur la façon dont nous avons remis nos API au centre de nos interfaces et, par la même occasion, au premier plan au côté des visualisations.

Petit historique de la ré-API-fication d’Explore

Au commencement était la version 1 de l’API (toujours en vigueur et pleine de fougue) et le portail Explore V2 (première version « industrielle »). Explore, dans sa vénérable version 2, était une application Web assez classique, avec génération des pages côté serveur. Si ce portail était stable et robuste, il était malgré tout assez contraignant à l’usage puisque chaque action même triviale (afficher les 50 lignes suivantes…) nécessitait un rechargement de la page; le côté « exploration » (affinage successif des données et changement de mode de visualisation à volonté) en devenait du coup plus rigide et l’utilisateur osait moins cliquer partout ou trop vite, ce qui est pourtant exactement ce que tout explorateur aime faire (mettez Indiana Jones devant un truc qui a un air menaçant mais plein de boutons…).

Séquence nostalgie: Explore V2

Début 2013, nous réarchitecturons et réécrivons donc l’intégralité du front-end. Les conditions sont posées : toutes nos interfaces seront basées sur nos API (pas le droit de tricher !), avec un focus sur le confort et la simplicité d’utilisation, le but étant de définitivement décapiter la phrase « la data c’est pas sexy ». Il est par ailleurs possible que quelques piliers de cette réécriture fassent un jour l’objet d’un article détaillé ici-même (les symbiotiques OpenStreetMap + Leaflet, et surtout AngularJS).

En avril 2013, nous publions enfin le résultat de ce travail long, acharné, passionnant, et jalonné de nombreux burgers. Outre le back-office qui a subit un changement intégral, l’interface Explore, dans sa désormais V3, est désormais devenue une application JS où l’utilisateur peut jouer avec les données et jongler entre les visualisations et les filtres de façon directe. Le changement de confort d’utilisation fût particulièrement frappant : réaction immédiate aux interactions, tout allant beaucoup plus vite (le temps de réponse étant purement le temps de l’aller-retour avec l’API). Et surtout, nous étions enfin basés entièrement sur notre API.

Le fait que l’interface Explore repose entièrement sur les interactions avec notre API de recherche nous a apporté les gains suivants:

• Nous sommes consommateurs de notre propre API, ce qui nous permet d’embrasser le dogfooding comme toute startup qui se respecte et qui a confiance en ses produits, et donc de mesurer directement les avantages et inconvénient de notre API (et de l’améliorer si besoin ou manque).
• Explore est devenu à la fois notre meilleure démo et la meilleure documentation « live » de notre API : il suffit de dégainer l’onglet Réseau du navigateur pour voir les appels d’API effectués à chaque action.
• En ayant « décollé » la visualisation du serveur pour la remettre côté client, et en la nourrissant par notre API, nous nous ouvrons beaucoup de portes en terme de réutilisation (comme la possibilité d’intégrer une visualisation interactive n’importe où en dehors du portail).

L’API comme fonctionnalité d’un portail Open Data

Dernièrement, nous avons eu l’idée d’exposer plus visiblement le rôle de l’API, par le biais d’un onglet dédié dans chaque jeu de données. Le but est double : d’abord, permettre à nos clients de mettre en avant l’API à travers une « passerelle » qui montre directement l’API en action, afin de donner envie aux développeurs de jouer avec et d’aller éventuellement consulter la documentation complète; ensuite, de promouvoir visuellement l’API au même niveau que le reste dans le portail, afin de montrer que l’API est réellement un outil de premier ordre, ce qui est crucial pour plusieurs de nos clients ayant un discours très centré autour des API et des écosystèmes d’applications.

La console d’API

Parce qu’un développeur est un être humain avec des sentiments et des yeux fragiles, il n’aime pas forcément découvrir et jouer avec une API en ligne de commande ou en tapant des adresses illisibles dans son navigateur. A l’occasion de la V3 d’Explore nous avons donc également réécrit notre console d’API, et celle-ci vient de subir une foule d’améliorations d’ordre pratique sous l’impulsion de notre prolifique stagiaire front-end Florent:

• L’adresse de la console est en permanence synchronisée avec son état (service choisi, paramètres) ce qui vous permet de partager simplement une console pré-remplie en envoyant directement l’URL
• La visualisation JSON du résultat est beaucoup plus rapide et pratique (possibilité de replier/déplier les objets; en sélectionnant tout ou partie du résultat, vous pouvez copier du JSON valide, et même les parties repliées seront collées)
• En ajoutant « console/ » après « api/ » à une URL d’API, vous arrivez directement sur la console pré-remplie pour cet appel : API / API Console