L’économie API à trouvé sa vitesse de croisière, et gagne du terrain. Le répertoire de ProgrammableWeb compte plus de 17.000 APIs. Nous commençons même à voir une consolidation du marché: les marketplaces Mashape et RapidAPI ont fusionné, créant un portail unique avec plus de 7.500 API répertoriées et permettant à Mashape de se concentrer sur ses produits de gestion d’API. Les principaux acteurs placent de gros paris: le cabinet de capital-risque Accel Partners est depuis longtemps optimiste sur le potentiel des APIs; en novembre dernier, Google a racheté la plateforme API Apigee.

Une nouvelle industrie prend forme autour des APIs. Pour comprendre la dynamique qui génère son avenir, il est aidant de jeter un regard vers le passé.

Dans les années 1980, les premiers fournisseurs de services Internet ont permis aux petites entreprises, sans grand moyens techniques, de s’interconnecter, quelques années seulement après avoir liés leurs propres ordinateurs par les réseaux locaux. Ces « îlots » de réseaux sont devenus des archipels, puis l’Internet et le Web que nous connaissons aujourd’hui.

Ce que les combinaisons de réseaux locaux et d’Internet a fait pour les communications numériques, la combinaison d’APIs et microservices va faire pour les applications.

Grâce aux APIs et aux microservices, ce que nous appelons « application » cessera d’exister, ou au moins, deviendra aussi absurde et sans intérêt qu’un ordinateur déconnecté. Les fonctionnalités souhaitées seront combinées et réassemblés ad hoc, à la demande, dans un but précis, avec une duré de vie dictée par ce but.

Bien sûr, cette vision reste hors de portée pour le moment, étant donné la grande diversité de méthodes, de techniques et d’architectures employés par les APIs actuels. Dans l’élan de notre enthousiasme pour créer de nouveaux outils logiciels, nous avons créé une sorte de Tour de Babel IT. Bien sûr, il existe des normes comme REST et GraphQL pour accéder aux APIs; et d’autres comme OpenAPISpec et RAML pour les définir. De nombreuses bonnes pratiques existent pour les opérations API simples, tels que l’incontournable CRUD (Créer / lecture ( « Read » ) / mise-à-jour ( « Update » ) / Suppression ( « Delete » )), qui permettent un accès à peu près cohérent aux APIs combinés de divers prestataires. Mais au-delà de ces ces opérations de base, le nombre croissant d’APIs est devenu un jeu global de Rien ne Va Plus.

La diversité est généralement une bonne chose. Les développeurs sont à juste titre soupçonneux de toute « dictature des normes » qui normalise l’architecture ou les comportements logiciels au détriment de la créativité ou de la flexibilité. D’autre part, chaque API utilisant sa propre approche, la communauté internationale de développeur API tire dans de nombreuses directions différentes. En conséquence, une grande quantité d’énergie — et de valeur — est perdue.

Comment pouvons-nous résoudre ce problème sans faire génuflexion devant des normes trop restrictives, et sans passer tout notre temps à intégrer des API pour les faire coexister dans un semblant d’harmonie?

C’est facile. Il suffit d’être ennuyeux.

Les APIs offrent plus de valeur quand ils sont ennuyeux — c’est à dire, lorsqu’ils ne vont pas trop loin dans les fonctionnalités ou services proposés au consommateur de l’API.

Ces fonctionnalités « ennuyeuses » offrent plus de valeur :

  • d’abord, en réduisant la complexité, facilitant la consommation cohérente de plusieurs APIs dans une seule application; et
  • en optimisant les compétences et points forts des développeurs qui emploient l’API. Lorsque les APIs fournissent des fonctionnalités nécessaires à l’application mais qui ne font pas partie de sa valeur de base — tels que « Enregistrer au format PDF », « Afficher la météo » ou « Notifier par mail » — les développeurs ont plus temps pour se concentrer sur les fonctionnalités qui rajoutent réellement de la valeur, ou augmentent le « sexy » de l’application.

Ainsi, pour la conception des APIs, l’ennuyeux est le nouveau sexy. Chez Hubrix, notre mission est d’exécuter des fonctionnalités ennuyeuses mais de grande qualité, afin que nos clients aient plus de temps à dévouer à la construction du sexy.

Cette approche vous intéresse ? Laissez-nous un commentaire. Ou mieux encore, exprimez-vous en
complétant notre sondage développeurs API 2017.

Merci!

Share This