Les API et les applications nous entourent quotidiennement. Qu’il s’agisse de web-applications complexes qui reproduisent les sensations d’une expérience native, c’est-à-dire d’une application de votre ordinateur (Gmail, Google Maps etc.) ou d’applications plus « simples » (Airbnb, Tripadvisor, Ebay, les e-commerces etc.), une logique d’arrière-plan va agir comme un émulsifiant et permettre à la mayonnaise de tenir : il s’agit des langages dits « back-end », qui fonctionnent sur le serveur pour délivrer une page au client.
Historiquement, un format = une application
Par le passé, les choses s’organisent autour de la base de données et le travail doit nécessairement être répliqué. Prenons l’exemple d’un service digital où un utilisateur créée un nouvel article. Sur le site internet de ce service, une logique sera créée (en php, ruby, python ou autre langage capable de communiquer avec le serveur) de telle sorte que lorsque l’utilisateur va créer un article, en utilisant le formulaire mis à sa disposition et en appuyant sur « envoyer », il sera enregistré dans la base de donnée et il sera disponible par exemple à l’URL http://www.monsupersite.fr/articles/:id-du-nouvel-article.
Tout cela est parfait. Mais lorsque vous voudrez créer une application iOS ou Android, vous devrez créer exactement la même logique en Objective-C ou Swift pour iOS et en Java pour Android. Autrement dit, vous allez devoir réinventer la roue trois fois pour aller exactement au même endroit. Une première solution serait d’utiliser les modules de création d’application hybrides depuis un site internet (Cordova, Phonegap) ; cela revient à encapsuler votre site internet dans une application native Android/iOS. Cela peut faire son office mais l’expérience utilisateur est très loin de la fluidité des applications natives. C’est ce chemin là qu’a suivi Facebook avant de développer une application native pour les deux plateformes :
Alors serait-il possible de rationaliser la conception d’applications pour permettre un déploiement sur différentes interfaces tout en restant DRY (Don’t Repeat Yourself) ? Les API permettent de répondre à cette problématique.
Les API viennent à notre secours
API signifie Applications Programming Interface ou interface de programmation applicative. C’est en fait une porte d’entrée par laquelle une autre application (tierce ou propriétaire si l’API est publique, propriétaire si l’application est privée) va pouvoir communiquer avec votre application principale. Un service qui fonctionne avec une API est dit API-centric. C’est grâce à l’API Google Maps que le site internet Google Maps s’actualise en fonction de l’URL.
Ainsi, l’URL
https://www.google.fr/maps/place/EFAP/@44.8501686,-0.573785,17z/data=!3m1!4b1!
4m5!3m4!1s0xd5527c83c300001:0x755af41fb0edfe48!8m2!3d44.8501686!4d-0.5715963
indique l’adresse de l’EFAP Bordeaux qui est à la latitude 44.8 et à la longitude –0.57 ; les données sont contenues dans la base de données, contrôlées par l’API et affichées à l’écran par différentes applications, dont le site Google Maps. L’application Android Google Maps est une autre manière de visualiser ces données en utilisant excatement la même API.
Un service organisé autour d’une API est un service centralisé. Toute la logique de l’application va se faire sur un serveur, avec un langage back-end, et des appels à cette API vont permettre d’actualiser l’état de la base de données. L’avantage est que ces appels se font généralement en respectant une convention (on parle d’API RESTful). Par exemple, si vous disposez dans votre base de donnée d’une table « clients », faire un appel à l’url www.votreapi.fr/clients/nouveau va permettre de créer un nouveau client. Cela va bien évidemment imposer que l’envoi des données à l’API ou la réception des données se fasse depuis une interface. Mais ce travail est bien plus simple que l’implémentation d’une logique entière pour chaque format. Ainsi, d’une application iOS qui devait elle-même prendre vos données, les vérifier et les sécuriser puis appeler la base de données, enregistrer les données, vérifier que cela s’est bien effectué puis vous envoyer une validation, désormais il lui suffira de prendre les données dans un formulaire, d’envoyer ce formulaire à l’adresse www.votreapi.fr/clients/nouveau (sous le verbe POST et au format JSON) et l’API se chargera du reste.
Les API, catalyseurs de la transformation numérique
Les API sont particulièrement intéressantes à l’heure où nous vivons une transition entre les applications web et les applications mobiles. Les usages sont multiples et il est important d’être présent sur toutes les plateformes. La conception initiale de l’API demande un peu plus de travail qu’un simple back-end de site internet mais à long terme et si le produit digital s’adresse à différents formats, ce regain se justifie.
Tant sur un plan d’usage que de création, les API permettent de faire des choses très intéressantes. Par exemple, il est possible de rendre WordPress API-centric avec le plugin RESTAPI. Dès lors, vous pouvez créer une application web ou native où vous ferez appel au contenu de vos articles de manière simple et sécurisée en profitant du back-end offert par WordPress.
Les possibilités sont infinies et certains comme IFTTT et Zapier l’ont compris ; ils utilisent les API publiques de différentes entreprises en permettant des connections et des automatisations, pour le plus grand bonheur des growth hackers en herbe.