Les entreprises s’appuient de plus en plus sur les API pour connecter les applications et les données entre les différents secteurs d’activité, s’intégrer à leurs partenaires et proposer des expériences client. Selon TechRadar, une entreprise utilise aujourd’hui en moyenne 15 564 API au total, soit une hausse de 201 % sur un an.
À mesure que le nombre d’API continue d’augmenter, la gestion de votre portefeuille d’API devient plus complexe. Il est de plus en plus difficile de répertorier et de suivre les API disponibles et leur emplacement, ainsi que de trouver de la documentation sur leur utilisation. En l’absence d’une stratégie globale en matière d’API, celles-ci peuvent proliférer plus vite que vos équipes chargées des opérations de plateforme ne peuvent les gérer. Nous appelons ce problème la prolifération des API et, dans un article précédent, nous avons expliqué pourquoi il constitue une menace si importante. Dans cet article, nous examinons en détail comment lutter contre la prolifération des API en mettant en place un portail pour les développeurs d’API avec l’aide de NGINX.
Dressez l’inventaire de vos API
En définitive, les API ne peuvent être utiles que si elles sont utilisées, ce qui signifie que leurs consommateurs doivent disposer d’un moyen de les trouver. En l’absence de systèmes adéquats, la prolifération des API complique la recherche, par les développeurs, de celles dont ils ont besoin pour leurs applications. Dans le meilleur des cas, les différentes branches d’activité tiennent leurs propres listes d’API et les connaissances sont partagées entre les équipes par l’intermédiaire de réseaux informels d’ingénieurs.
L’une des premières étapes pour lutter contre la prolifération des API consiste à créer une source unique de vérité pour vos API. Ce processus commence par l’établissement d’un inventaire de vos API. Il est toutefois difficile de tenir un inventaire précis, car celui-ci évolue constamment à mesure que de nouvelles API sont introduites et que d’anciennes deviennent obsolètes. Vous devez également repérer les « API fantômes » dans vos différents environnements, c’est-à-dire les API qui ont été oubliées au fil du temps, qui ont été mises hors service de manière incorrecte ou qui ont été créées en dehors de vos processus habituels.
Les API non gérées constituent l’un des symptômes les plus insidieux de la prolifération des API, avec des conséquences évidentes sur la sécurité et des coûts cachés. Sans inventaire précis des API disponibles, vos équipes chargées des API doivent consacrer du temps à rechercher la documentation. Le risque que différentes équipes développent des fonctionnalités similaires, entraînant ainsi une duplication inutile des efforts, est considérable. De plus, sans gestion appropriée des versions, toute modification apportée à une API peut entraîner de coûteuses séries de reprises, voire des interruptions de service.
Des techniques telles que la découverte automatisée des API peuvent vous aider à identifier et à traiter le symptôme que constituent les API non gérées. Mais pour résoudre le problème, vous devez en éliminer les causes profondes : des processus défaillants et un manque de responsabilisation. En pratique, l’intégration de l’inventaire et de la documentation des API dans vos pipelines CI/CD est la seule approche qui garantit une visibilité à long terme sur l’ensemble de votre portefeuille d’API. Au lieu de devoir suivre manuellement chaque API lors de sa mise en service, il vous suffit d’identifier et de corriger les exceptions.
Simplifiez la découverte des API grâce à un portail pour développeurs d’API
Un portail pour développeurs d’API peut notamment contribuer à simplifier la découverte des API. Il offre aux utilisateurs d’API un espace centralisé où ils peuvent découvrir des API, consulter leur documentation et les tester avant de les intégrer à leurs applications. Votre portail pour développeurs d’API peut également faire office de catalogue central des API, avec des informations sur leurs propriétaires et leurs coordonnées, afin que chacun sache qui est responsable de la maintenance des API pour les différents services.
Composant essentiel de notre architecture de référence des API<.htmla>, un portail développeur d’API efficace permet de répondre à plusieurs cas d’usage clés :
- Simplifiez la découverte des API – Publiez vos API dans un emplacement accessible afin que les développeurs puissent facilement les trouver et les utiliser dans leurs projets
- Fournissez une documentation claire et à jour – Veillez à ce que les développeurs aient toujours accès à la documentation la plus récente sur le fonctionnement d’une API
- Assurer une gestion appropriée des versions – Introduisez de nouvelles versions d’une API sans provoquer d’interruptions pour les applications en aval, grâce à la prise en charge du versionnage
- Générer des identifiants d’API – Simplifiez le processus d’intégration afin que les développeurs puissent se connecter et générer des identifiants pour accéder à l’API
- Tester les API – Permettez aux développeurs de tester les API sur le portail avant de les intégrer à leurs projets
Créez une source unique de vérité pour vos API avec NGINX
API Connectivity Manager, qui fait partie de F5 NGINX Management Suite, vous aide à intégrer la publication, la gestion des versions et la documentation des API directement dans vos workflows de développement, afin que votre portail pour développeurs d’API soit toujours à jour. En plus de faciliter la création de portails pour développeurs destinés à héberger vos API et leur documentation, API Connectivity Manager vous permet d’ajouter des pages personnalisées et d’adapter entièrement le portail à votre image de marque.
Voyons comment API Connectivity Manager vous aide à répondre à certains cas d’usage spécifiques. Consultez la documentation d’API Connectivity Manager pour obtenir des instructions détaillées sur la configuration d’un cluster de portails pour développeurs et la publication d’un portail pour développeurs.
Générer automatiquement la documentation de l’API
Il existe souvent un fossé considérable entre le niveau de qualité et de détail que les utilisateurs de votre API attendent de la documentation et ce que vos développeurs d’API, très sollicités, peuvent raisonnablement fournir avec des ressources et un temps limités. De nombreux outils de documentation développés en interne ne s’intègrent pas au cycle de développement ni aux autres systèmes d’ingénierie. Pourtant, ce n’est pas une fatalité.
Comment NGINX peut vous aider : API Connectivity Manager utilise la spécification OpenAPI pour publier les API sur la passerelle d’API et générer automatiquement la documentation correspondante sur le portail des développeurs, ce qui permet aux développeurs d’API de gagner du temps et garantit que les utilisateurs d’API trouvent toujours ce dont ils ont besoin. Vous pouvez importer des fichiers de spécification OpenAPI directement depuis l’interface utilisateur d’API Connectivity Manager ou en envoyant une requête via l’API REST. Vous pouvez ainsi facilement automatiser le processus de documentation au moyen de votre pipeline CI/CD.
Pour publier de la documentation dans API Connectivity Manager, cliquez sur « Services » dans la colonne de navigation de gauche pour ouvrir l’onglet « Services ». Cliquez sur le nom de votre espace de travail ou créez-en un nouveau.
Une fois dans l’espace de travail, cliquez sur API Docs sous l’encadré contenant le nom et la description de votre espace de travail (example-api dans la capture d’écran). Cliquez ensuite sur le bouton Add API Doc pour importer votre fichier de spécification OpenAPI. Cliquez sur le bouton Save pour publier la documentation sur le portail des développeurs.
Figure 1 : Création d’une documentation en téléversant un fichier de spécification OpenAPI dans
API Connectivity Manager
Assurer une gestion appropriée des versions
Les changements de version doivent toujours être gérés avec précaution, en particulier dans les environnements de microservices où de nombreux services peuvent interagir avec une même API. Sans une approche rigoureuse pour introduire de nouvelles versions et retirer les anciennes, une seule modification entraînant une rupture de compatibilité peut provoquer une panne en cascade touchant des dizaines de microservices.
Comment NGINX peut vous aider : L’utilisation de fichiers de spécification OpenAPI avec API Connectivity Manager facilite la gestion des versions de vos API. Outre la définition du numéro de version, vous pouvez fournir une documentation pour chaque version et gérer son statut (la plus récente, active, retirée ou obsolète).
Pour publier une nouvelle version d’une API, cliquez sur « Services » dans la colonne de navigation de gauche. Cliquez sur le nom de votre espace de travail dans le tableau, puis sur le nom de votre environnement dans la page qui s’ouvre. Cliquez ensuite sur le bouton + Add Proxy. Vous pouvez alors charger la spécification OpenAPI, définir le chemin de base et la version afin de créer l’URI (par exemple, /api/v2/), puis saisir d’autres métadonnées importantes. Cliquez sur le bouton Publish pour enregistrer et publier votre proxy d’API.
La version d’origine de l’API reste disponible parallèlement à la nouvelle version. Vos utilisateurs ont ainsi le temps de migrer progressivement leurs applications ou services vers la version la plus récente. Lorsque vous êtes prêt, vous pouvez rendre complètement obsolète la version d’origine de votre API. La figure 2 montre deux versions de l’API Sentence Generator publiées et en production.
Figure 2 : Gestion des versions actives de l’API dans API Connectivity Manager
Générer des identifiants d’API
Pour favoriser l’adoption de vos API, vous devez simplifier autant que possible le processus d’intégration pour leurs utilisateurs. Une fois qu’ils ont trouvé les API qui les intéressent, les utilisateurs doivent pouvoir se connecter de manière sécurisée au portail des développeurs et générer des identifiants. Ces identifiants leur donnent accès aux fonctionnalités de votre API. Dans la plupart des cas, il est préférable de mettre en place un processus en libre-service afin que les utilisateurs puissent s’inscrire de manière autonome.
Comment NGINX peut vous aider : API Connectivity Manager prend en charge les workflows d’API en libre-service sur le portail des développeurs, afin que les utilisateurs puissent générer leurs propres identifiants d’accès aux ressources pour accéder aux API. Ces identifiants peuvent être gérés sur le portail à l’aide de clés d’API ou de l’authentification HTTP Basic. Vous pouvez également activer l’authentification unique (SSO) sur le portail des développeurs afin de sécuriser l’accès et de permettre aux consommateurs d’API authentifiés de gérer leurs identifiants d’accès aux ressources.
Pour activer rapidement l’authentification unique (SSO) sur le portail des développeurs, cliquez sur « Infrastructure » dans la colonne de navigation de gauche. Cliquez sur le nom de votre espace de travail dans le tableau (dans la figure 3, il s’agit de team-sentence).
Figure 3 : liste des espaces de travail dans l’onglet Infrastructure
Dans le tableau de la page Workspace, cliquez sur le nom de l’environnement que vous souhaitez configurer (dans la figure 4, il s’agit de « prod »).
Figure 4 : liste des environnements dans un espace de travail
Dans la section Clusters du portail des développeurs, cliquez sur l’icône … dans la colonne Actions du portail des développeurs sur lequel vous travaillez, puis sélectionnez Modifier la configuration avancée dans le menu déroulant. Dans la figure 5, l’unique cluster du portail des développeurs est devportal-cluster.
Figure 5 : sélection de l’option « Edit Advanced Config » pour un cluster de portail développeur
Ensuite, cliquez sur Politiques globales dans la colonne de navigation de gauche. Configurez la stratégie de partie utilisatrice OpenID Connect en cliquant sur l’icône « … » dans la colonne « Actions » de la ligne correspondante, puis en sélectionnant Modifier la stratégie dans le menu déroulant. Pour plus d’informations, consultez la documentation d’API Connectivity Manager.
Figure 6 : Configuration de la stratégie globale de partie de confiance OpenID Connect pour activer l’authentification unique
Tester les API sur le portail des développeurs
Pour mesurer le succès de votre stratégie d’API, vous pouvez notamment suivre l’indicateur « délai avant le premier appel d’API », qui indique le temps nécessaire à un développeur pour envoyer une requête simple à l’aide de votre API.
Nous avons établi qu’une documentation claire et concise est essentielle en tant que premier point d’entrée de votre API, car elle permet à vos utilisateurs de comprendre les principes de base de son utilisation. En général, les développeurs doivent ensuite écrire du code pour intégrer l’API à leur application avant de pouvoir tester des requêtes API. Vous pouvez les aider à démarrer beaucoup plus rapidement en leur permettant d’interagir directement avec une API depuis le portail des développeurs à l’aide de données réelles, et ainsi d’effectuer leur premier appel API sans écrire une seule ligne de code pour leur application !
Comment NGINX peut vous aider : Une fois l’authentification unique (SSO) activée pour vos portails de développeurs API Connectivity Manager, les utilisateurs de l’API peuvent utiliser l’explorateur d’API pour tester des appels d’API depuis vos pages de documentation. Ils peuvent ainsi explorer les points de terminaison, les paramètres, les réponses et les modèles de données de l’API, et tester des appels d’API directement dans leur navigateur.
La figure 7 montre l’Explorateur d’API en action – ici, lors d’un essai de l’API Sentence Generator. L’utilisateur sélectionne les identifiants appropriés, crée la requête et reçoit une réponse contenant des données réelles provenant de l’API.
Figure 7 : test d’une API sur le portail des développeurs
Résumé
Les API sont essentielles à votre organisation. La première étape pour les gouverner et les sécuriser consiste à recenser chacune d’entre elles, où qu’elle se trouve. Mais la découverte des API n’est qu’une partie de la solution : vous devez intégrer l’inventaire, la documentation et la gestion des versions des API à votre cycle de développement et d’ingénierie afin de traiter les causes profondes de leur prolifération.
Commencez un essai gratuit de 30 jours de NGINX Management Suite, qui inclut l’accès à API Connectivity Manager, à NGINX Plus en tant que passerelle d’API et à NGINX App Protect pour sécuriser vos API.
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.