Techniques pour prendre le contrôle de la prolifération indisciplinée des API

Getty Images

Si rien n’est fait, un large portefeuille d’API peut rapidement devenir un problème majeur – et une responsabilité coûteuse – pour les entreprises. Sans une stratégie API et une standardisation bien définies, les applications peuvent facilement devenir incontrôlables et provoquer une prolifération des API.

Lorsque la prolifération des API se produit, des inefficacités telles qu'une duplication des efforts de développement sur des fonctionnalités d'application redondantes peuvent s'infiltrer, nécessitant des investissements plus élevés pour la maintenance et augmentant la complexité du système. Le besoin d’une compatibilité ascendante pour de nombreux consommateurs peut être extrêmement complexe et coûteux. Plusieurs sources de vérité peuvent également conduire à des conflits de données, entraînant de mauvaises expériences et une ambiguïté susceptible de nuire à l'adoption.

Dans cet article, nous examinerons quelques stratégies globales que les équipes logicielles peuvent mettre en œuvre pour empêcher la prolifération des API ou, si nécessaire, reprendre le contrôle d'un portefeuille d'API déjà mal géré.

La gestion d'une prolifération incontrôlée d'API nécessite des efforts concentrés de la part des équipes logicielles pour garantir qu'elles peuvent maintenir la complexité globale, le coût du changement et la maintenance d'urgence au minimum.

Lutter contre la prolifération des API commence par déterminer l’étendue globale de l’impact d’une API sur les opérations et la consommation des ressources. Souvent, les API peuvent interagir avec des entités logicielles à la fois au sein de l’organisation et à l’extérieur de ses frontières. La portée de l’impact des API est souvent limitée lorsque les consommateurs, qu’ils soient internes ou externes, y sont explicitement intégrés.

Les API accessibles au public peuvent représenter un degré de complexité de gestion nettement plus élevé. Outre la classification par portée d'impact - qui peut inclure un certain nombre de composants et de points finaux indépendants de la volonté de l'organisation - une API publique unique peut souvent incarner plusieurs formats de données, normes de sécurité et protocoles de communication. Il est donc impératif d’identifier l’étendue de la fragmentation lors de la mise en œuvre des contrats et des protocoles.

Parfois, les API devront migrer entre les systèmes au cours de leur cycle de vie. Pour permettre une transition en douceur, les équipes logicielles devront préparer les API avant la migration afin de s'assurer qu'elles conservent l'état souhaité. Pour réduire les problèmes de transition, cela peut également nécessiter de calibrer la migration afin que les API migrent lentement au fil du temps plutôt qu'en masse. Certaines techniques de base de gestion des versions d'API peuvent s'avérer utiles à cet égard, par exemple en permettant aux consommateurs de migrer vers des versions plus récentes alors que les anciens contrats sont obsolètes. Les équipes peuvent également créer des bibliothèques accessibles pour les environnements d'exécution populaires, créer des couches de compatibilité pour les API les plus récentes ou ajouter des indicateurs de fonctionnalités spécifiques aux consommateurs pour faciliter une migration transparente.

Une fois le paysage existant et son impact bien compris, les étapes suivantes devraient se concentrer sur la convergence des normes existantes. Cette étape peut être exécutée en trois « sous-étapes », que nous examinerons ci-dessous.

Les équipes doivent régulièrement mesurer et analyser l'utilisation des API dans l'ensemble des environnements. Les domaines dans lesquels il n'existe pas ou peu de contrôle sur les consommateurs d'API peuvent nécessiter l'aide d'outils ou de plates-formes de gestion d'API prenant en charge des fonctionnalités telles que la simulation. Identifiez les principaux domaines d'exposition, les fonctionnalités critiques et tous les formats d'API existants.

Les API des grands portefeuilles non gérés peuvent souvent présenter des comportements redondants qui conduisent à une duplication des sources d'informations et des efforts de développement. Il est important de lever l'ambiguïté des sources en traçant des limites de domaine strictes pour les classifications des API et, peut-être plus important encore, les responsabilités de gestion. Cela peut nécessiter la création de nouvelles API qui sont des « versions consolidées » des anciennes, la dépréciation des API existantes jugées redondantes ou simplement la mise à jour des contrats des API existantes pour en restreindre la portée.

Une fois la consolidation fonctionnelle effectuée, il est important d'établir des conventions définitives qui s'alignent sur les besoins et les objectifs de l'entreprise qui, en fin de compte, traceront la voie aux transitions ainsi qu'aux nouveaux développements. Documenter et schématiser ces relations contribuera grandement à construire un consensus plus large sur des éléments tels que les structures contractuelles et les protocoles sous-jacents.