Les API c’est bien… en abuser ça craint !
API, API, API… elles sont partout, on en met à toutes les sauces, c’est presque devenu une mode et un buzz-word indispensable à tout bon pitch digital.
Oui, les API c’est bien, c’est vraiment bien, par exemple pour permettre l’accès (contrôlé) à des données internes et à standardiser leur accès. C’est même indispensable dans certains cas, par exemple lorsque les données évoluent très vite, ou qu’elles sont trop volumineuses pour être accessibles en simple téléchargement, voire une combinaison des deux.
Par exemple des données sur la disponibilité ou l’état en temps réel du réseau de transport public sont difficiles à partager et à utiliser sans API.
Des données très volumineuse comme une couverture d’images satellite ou aériennes permettent de n’accéder qu’à quelques images sur une zone limitée sans avoir à manipuler des terra-octets d’imagerie. De même lorsqu’on consulte une partie du fond de carte OpenStreetMap en quelques images alors que la base mère pèse plusieurs centaines de Go.
Standardiser l’accès
Une API peut permettre de standardiser l’accès à des données. On le voit très bien dans le domaine des données géographiques, où des protocoles et API standardisées permettent d’accéder à des données géographiques sans avoir à connaître le format ou l’organisation des données en interne derrière l’API.
Dans le cas des moteurs de géocodages, une ébauche de standardisation existe aussi entre plusieurs outils libres: photon, addok, metaddok. On peut du coup passer d’un service à l’autre sans ré-écriture du côté du client.
Des services qui ne sont pas universels
C’est en effet une des limites des API, elles prévoient une certaine offre de service qui peut être limitée par rapport à ce que permettent les données sous-jacentes.
Une API de géocodage ne permettra pas de produire par exemple des statistiques de densité d’adresses, ce n’est pas son rôle. Elle ne vous donnera pas les adresses proches de celle recherchée… sauf si ça a été prévu bien sûr (en général ça ne l’est pas).
Si nous voulons faire de l’analyse d’images sur nos photos satellites ou aériennes, le chargement par petites imagettes sera bien moins efficace que de travailler sur de grandes dalles couvrant plusieurs kilomètre carrés.
Lorsque le seul accès aux données se fait via une API, rares sont celles qui permettent de récupérer de grand volumes de données. On doit donc souvent faire de nombreux appels pour accéder à l’intégralité des données voire juste une portion importante (scrapping sur API). Ces requêtes sont coûteuses en ressources informatiques et en trafic réseau, là où une mise à disposition d’un fichier téléchargeable aurait été bien plus économique quand elle est possible.
Le syndrome de l’amnésie
Lorsque des données évoluent dans le temps (et c’est souvent le cas pour celles diffusées par API), les API permettent en général que d’avoir accès au dernier état. On perd donc tout l’historique, car là encore un type d’usage principal a été envisagé pour la mise en œuvre de l’API, en ignorant d’autres usages possibles.
Obtenir l’état de disponibilité des Vélib en temps réel est un service utile, mais l’historisation est aussi très utile pour permettre de faire des analyses prédictives, des statistiques, de voir l’évolution dans le temps. Quand Vélib 2.0 est en roue libre, pouvoir comparer avec l’état de Vélib 1.0 aux mêmes dates il y a 1, 2 ou 3 ans est fort intéressant… et pour ça, à moins que l’API n’ait prévu un accès à l’historique il faut se rabattre vers les “scrapping” plus ou moins sauvages qui ont été faits. Avec la fin du contrat Decaux, que sont devenues ces données ?
Une diffusion de fichiers téléchargeables, si possible historisés est très complémentaire d’une diffusion par API et permet d’autres types de réutilisations que celles envisagées par les services proposés par l’API.
Des services à valeur ajoutée ou de confort
Dans certains cas, une API offre un service à valeur ajoutée sur des données brutes disponibles par ailleurs. Par exemple l’API de géocodage proposée sur adresse.data.gouv.fr permet de tirer parti de la Base Adresse Nationale de façon bien plus utile que le simple accès aux fichiers de référence.
Ceux-ci sont bien entendu disponibles en téléchargement, sans passer par l’API pour permettre d’autres usages ou services que ceux proposés car une API ne peut pas être assez universelle pour prévoir tout type d’usage et de réutilisation des données… ou alors elle devient une usine à gaz.
Dans certains cas, l’API n’apporte pas de réelle valeur ajoutée, à part un confort pour des développeurs un peu paresseux qui se contenteront d’appeler une nième API pour obtenir une information qu’ils auraient très bien pu gérer par eux-mêmes, parfois au sein même de l’application cliente.
C’est typiquement le cas pour des données qui ne changent que très rarement et qui ne sont pas volumineuses. Appeler par exemple une API de géocodage pour obtenir le nom d’une commune (parmi désormais moins de 35000) à partir d’un code postal n’est pas forcément pertinent et cela pose un vrai problème de dépendance forte pour un service à valeur ajoutée au final très faible.
Disponibilité et dépendance: l’effet dominos
Plus une application fait usage à des API pour son fonctionnement, plus celle-ci est sensible à l’indisponibilité ou au changement de comportement des API dont elle dépend.
Une API avec un taux de disponibilité de 99.9%, pourra être indisponible jusqu’à 9h par an, à 99,5% c’est presque 2 jours d’indisponibilité.
Une application qui utiliserait plusieurs API doit additionner ces indisponibilité… avec 3 API à 99.9% on dépasse la journée, et à 99.5% on passe à la semaine indisponible !
Il faut donc être bien conscient de cette dépendance et de l’effet dominos associé. Quand des API s’appuient sur d’autres API pour fonctionner, l’effet multiplicateur peut être encore plus important.
La disponibilité dépend en plus de beaucoup d’éléments indirects comme le réseau (qui doit bien sûr fonctionner de bout en bout), mais aussi d’éléments parfois oubliés mais qui sont eux aussi sur le chemin critique (ce nom de domaine ou certificat qu’on a oublié de renouveler ou ce DNS mal configuré ou injoignable pour cause de DDoS).
Il y a malheureusement toujours un single point of failure… celui qu’on a oublié ;)
Les API évoluent aussi dans le temps et ça aussi c’est un facteur de risque… il faudra adapter le client au fur et à mesure. Les API correctement versionnées (qui maintiennent plusieurs versions en parallèle) sont plus l’exception que la règle car souvent coûteuse à maintenir et ne sont pas éternelles… et il faut qu’elles prévoient une période de transition suffisamment longue (au moins 6 mois voire plusieurs années) pour que ses clients puissent s’adapter car les développements informatiques, même en agile, sont rarement de la génération spontanée.
Contrôle d’usage et d’accès
Les requêtes traitées par une API nécessitent donc des ressources réseau et bien sûr informatiques. Pour avoir des temps de réponse faibles, un taux de disponibilité élevé, il faut des serveurs correctement dimensionnés, avec du code correctement optimisé, de la redondance… ceci a un coût qui peut être marginal mais qui n’est pas toujours faible lorsqu’on le multiplie par des milliards d’appels.
Aussi, pour maîtriser ces coûts, il est tentant de contrôler l’usage. Ceci peut se faire souvent, simplement et de façon transparence pour les clients de l’API en fixant une limite en requêtes par seconde depuis une adresse IP. Sur les API que j’administre c’est ce que je fais et c’est amplement suffisant sans passer à l’étape suivante des tokens.
Le recourt aux tokens, donc à une identification préalable de l’utilisateur est rarement indispensable pour des raisons techniques et est plus souvent guidé par un besoin de savoir qui fait quoi, voire d’avoir en tête ou comme objectif un système de facturation.
Ces tokens viennent s’ajouter aux problèmes de disponibilité… le token non renouvelé ou non mis à jour dans le client ? bien sûr que ça arrive !
Une API avec token est parfois indispensable pour limiter et contrôler l’accès au cas par cas sur des données non librement diffusables (données couvertes par des secrets comme le secret fiscal). C’est par exemple le cas de l’API Entreprise où un token est pleinement justifié.
Les API dans le cadre de l’opendata…
Un des principes de l’opendata c’est de ne pas présager des réutilisations qui seront faites de données, mais aussi de ne pas limiter celles-ci.
Une diffusion par API, limite forcément les possibilités de réutilisation, car l’API est adaptée à certains usages, elle ne peut pas être universelle.
Elle ne permet pas non plus un usage illimité, car techniquement il faudra absorber la charge de requêtes et ceci aura un coût.
Même si la licence sous laquelle sont diffusées des données par une API est bien une licence libre, une diffusion uniquement par API ne répond donc pas aux critères d’opendata, ni aux critères de réutilisation des informations publiques définis par les textes existants en France.
C’est le cas avec opencorporate qui diffuse les données sous licence ODbL mais uniquement par API et avec un volume limité de requêtes. Ceci n’est pas de l’opendata, ici c’est carrément de l’openwashing.
Pour autant, les API peuvent apporter un réel service en complément d’une diffusion par fichiers.
Comme souvent, il faut réfléchir à ce qui est adapté et ne pas avoir de position de principe, position souvent liée à une mode ou une méconnaissance du sujet et des conséquences.
