Qu’est-ce que le cycle de vie des API ?

Les API sont des ensembles de règles ou de protocoles qui permettent aux applications logicielles de communiquer entre elles pour échanger des données, des caractéristiques et des fonctionnalités. Il existe à la fois un cycle de vie du producteur d’API, axé sur la création et la distribution d’API, et un cycle de vie du consommateur d’API, centré sur l’utilisation de l’API du point de vue du consommateur. Cet article se concentre sur le cycle de vie du producteur d’API.

Il n’existe pas de cycle de vie universel pour les producteurs d’API. Vous pourriez observer différentes variations selon les sources, mais le cycle de vie comprend généralement les étapes suivantes : planifier, concevoir, développer, tester, déployer, surveiller et mettre hors service.

Les plateformes de gestion des API sont souvent utilisées pour aider à organiser les efforts tout au long du cycle de vie de l’API, ainsi que pour centraliser la stratégie, la gouvernance, la documentation et les référentiels liés à l’API dans un environnement informatique. De nombreuses plateformes incluent des capacités d’analytiques avancées et des outils pour la découverte et la monétisation des API qui aident les entreprises à tirer le meilleur parti de leurs API.

La prise en compte et la compréhension de l’ensemble du cycle de vie des API aident les équipes de développement à allouer les ressources plus efficacement, à établir des délais réalistes pour la livraison, à tenir toutes les parties prenantes informées tout au long du processus et à s’assurer que les API répondent aux exigences métier. Essentiellement, un cycle de vie bien pensé et bien exécuté permet d’obtenir des API performantes et sécurisées, tout en renforçant l’expérience utilisateur.

La gestion du cycle de vie des API de bout en bout comprend plusieurs étapes clés, à commencer par la planification préliminaire et se terminant, souvent mais pas toujours, par le retrait ou le remplacement. Prenons l’exemple d’un éditeur de logiciels qui décide de créer une API pour synchroniser ses données clients avec des outils professionnels tels que les tickets d’assistance, les systèmes de comptabilité, les plateformes de gestion de projet, etc.

La création d’une API commence par répondre à quelques questions fondamentales : pourquoi cette API est-elle nécessaire, à qui est-elle destinée, comment sera-t-elle utilisée et comment sera-t-elle mesurée ? 

La précision de l’objectif du projet d’API peut aider à clarifier les caractéristiques et les fonctionnalités dont la conception de l’API doit disposer. Dans l’exemple du développement logiciel, l’objectif de l’API est de garantir que les données client puissent circuler de façon fluide entre les applications et les plateformes que l’entreprise utilise ou prévoit d’utiliser. 

Lors de cette phase de planification, les entreprises doivent :

• Examiner les avantages commerciaux potentiels de l’API
• Décrire comment cette API répond aux besoins métier
• S’assurer qu’il n’y a pas d’API ou d’autres produits disponibles sur les marketplaces d’intégrations natives qui pourraient faire ce qui est requis (c’est-à-dire, confirmer que la création de cette API est nécessaire)
• Définir clairement quelles applications et plateformes dépendront de l’API et comment celle-ci s’intégrera aux workflows existants

Ensuite, l’équipe doit discuter des utilisateurs potentiels et des cas d’utilisation. Est-elle exclusivement destinée à un usage interne ? Quelles équipes utiliseront cette API, et pour quoi ? Existe-t-il des problèmes de sécurité qui devraient être abordés lors des phases de conception et de développement ? Et surtout, qui sera responsable de chaque phase de production de l’API ?

Fixer un calendrier pour l’achèvement du projet permet de s’assurer que le budget est respecté. Les échéanciers doivent être réalistes et flexibles. 

Les équipes répondront à des questions telles que : Y a-t-il des dates spécifiques à respecter, comme la date de lancement d’une nouvelle fonctionnalité ? Y a-t-il des équipes chargées de la sécurité, de la conformité juridique, ou d’autres parties prenantes qui doivent donner leur accord avant que cette API ne puisse être déployée ? 

Où la documentation et les autres informations relatives à l’API seront-elles stockées et mises à la disposition des développeurs et des utilisateurs ? Où les modifications de code pourront-elles être consultées et stockées ?

Répondre à ces questions dès le départ permet d’établir un plan clair pour la suite du cycle de vie.

Alors que la phase de planification décrit le résultat souhaité, la phase de conception définit la manière dont l’équipe prévoit d’y parvenir. Tout au long du processus de conception, l’équipe chargée de la conception de l’API décide de la manière dont l’API doit être conçue pour répondre aux exigences détaillées lors de la phase de planification. 

L’équipe doit prendre des décisions de conception concernant le protocole et le style architectural que l’API utilisera. Cette décision peut être basée sur l’architecture d’API existante au sein de l’entreprise ou sur les cas d’utilisation prévus pour cette nouvelle API.

Par exemple, les cadres et architectures d’API les plus courants sont REST, GraphQL et gRPC, chacun ayant ses propres forces et faiblesses. 

• REST : simple, intuitif et omniprésent, mais il n’est pas idéal pour les requêtes complexes et n’offre pas de typage robuste.
  
  
• GraphQL : efficace, avec un typage robuste et une documentation intégrée. GraphQL peut aussi être complexe et nécessiter plus de configuration et d’expertise spécifique que REST.
  
  
• gRPC : rapide, avec un typage robuste, une génération automatique de code et une diffusion bidirectionnelle. gRPC est souvent utilisé pour la communication entre microservices. Cependant, en tant que nouveau cadre, il peut y avoir une courbe d’apprentissage. De plus, son format de documentation est binaire plutôt que lisible par l’homme. 

Lors de la conception de l’API, l’équipe décidera également du type d’authentification approprié (comme OAuth 2.0) et si l’API doit être protégée par une passerelle API.

Un document de spécification décrit la structure, le comportement et la fonctionnalité d’une API de manière standardisée. Il fournit une source d’information unique sur la façon dont l’API est construite, ce qu’elle peut faire et comment interagir avec elle. 

La spécification standardisée la plus utilisée est la spécification OpenAPI, qui permet aux développeurs de définir des chemins, des méthodes, des paramètres, des méthodes d’authentification, etc. OpenAPI est spécifiquement utilisée pour les API REST et prend en charge un ensemble d’outils open source appelés Swagger, qui permettent la génération de code, l’édition et la création automatique de documentation.

Pour GraphQL, la spécification équivalente est le schéma GraphQL, un contrat fortement typé écrit dans un langage de définition de schéma (SDL), un format lisible par l’homme. L’écosystème GraphQL offre quelques outils différents qui tirent parti de ce schéma de manière à proposer des fonctionnalités similaires à celles d’OpenAPI ; par exemple, GraphiQL est un écosystème de développement intégré (IDE) au navigateur que les développeurs peuvent utiliser comme un bac à sable. 

Pour gRPC, Protocol Buffers, ou Protobuf, est un format de sérialisation et un langage de définition d’interface (IDL) servant de format de fichier le plus couramment utilisé pour les spécifications. Protobuf n’offre pas de tests interactifs, bien qu’il existe des interfaces utilisateur web qui le permettent. 

À ce stade, les développeurs commencent à coder, en suivant le plan de conception de l’API décrit à l’étape précédente. Un système de contrôle des versions est utilisé pour suivre les versions et les modifications de code tout au long du processus de développement.

La norme industrielle pour les systèmes de contrôle de version est Git, un logiciel open source qui permet de suivre les modifications apportées au code stocké localement sur l’appareil du développeur. Les développeurs utilisent Git pour créer, gérer et suivre les modifications de leur code, mais ont ensuite besoin d’un espace accessible pour eux-mêmes et pour les autres. 

GitHub est le service d’hébergement Git le plus populaire, offrant des niveaux gratuits et payants, permettant le stockage, la récupération et la collaboration des référentiels de code Git. Il existe des alternatives pour héberger des référentiels Git, notamment GitLab, AWS CodeCommit et Microsoft Azure Repos.

Le test des API est effectué pendant et après la phase de développement de l’API. Les tests continus facilitent le développement en révélant les vulnérabilités et les besoins, et en permettant des mises à jour régulières. 

Les tests unitaires consistent à isoler de petites parties du code et à les tester individuellement. Dans l’exemple de l’API de notre éditeur de logiciels, supposons que l’équipe doive tester la réponse à une demande visant à récupérer les informations d’un utilisateur. La commande GET doit récupérer le nom et l’adresse e-mail d’un utilisateur à partir du numéro d’identification de cet utilisateur dans une base de données client. Les tests unitaires consisteraient à s’assurer que cette requête GET récupère les informations voulues et qu’une requête portant sur un identifiant inexistant renvoie un message d’erreur approprié.

Les tests d’intégration sont généralement exécutés après les tests unitaires et sont utilisés pour détecter les problèmes que les tests unitaires n’ont pas détectés. Les tests d’intégration permettent de s’assurer que plusieurs composants ou services peuvent communiquer comme prévu via l’API. 

Revenons à notre exemple. Supposons que l’une des fonctionnalités de l’API soit l’envoi d’un webhook, ou d’une notification, d’un système à l’autre en cas d’événement particulier, tel que l’ajout d’un nouveau client. Pour s’assurer que cela fonctionne, un test d’intégration est mis en place avec un faux serveur qui reçoit une notification et effectue l’action prévue lorsque les informations d’un nouveau client sont ajoutées au CRM. Ce processus est répété pour toutes les intégrations.

Les tests des contrats d’API garantissent que l’API répond aux attentes des utilisateurs. Le contrat se présente généralement sous la forme d’un fichier de spécification OpenAPI, qui est un document standard, lisible par une machine, décrivant les éléments de la fonctionnalité et des capacités d’une API. Un fichier de spécification API est généralement écrit en JSON ou YAML et contient des éléments tels que les points de terminaison API, les méthodes d’authentification, les formats spécifiques des requêtes et réponses acceptables, les métadonnées et les paramètres d’entrée.

L’évaluation des performances d’une API implique généralement d’évaluer sa vitesse et son efficacité. À cette étape, les testeurs cherchent à mesurer le temps de réponse à la requête, les taux d’erreur, l’utilisation des ressources (comme l’utilisation du processeur et de la mémoire), la latence et le rendement. Comprendre les performances d’une API à ce stade peut aider à détecter les goulots d’étranglement ou les redondances susceptibles de ralentir l’expérience utilisateur.

Les API sont souvent utilisées pour transmettre des données sensibles, faisant des tests de sécurité un élément essentiel. Les tests de sécurité des API visent essentiellement à déchiffrer l’API de différentes manières pour garantir la sécurité et la stabilité. Ces tentatives peuvent inclure des tests de validation des entrées afin de s’assurer que les données ne sont acceptées que lorsqu’elles sont saisies dans des formats approuvés au préalable. 

Les tests de validation des entrées permettent de détecter différents types d’attaques. Les types d’attaques les plus courants incluent l’injection SQL, au cours de laquelle des acteurs malveillants insèrent du code malveillant dans une application. Le SQL est un langage utilisé pour communiquer avec des bases de données, certaines commandes SQL universelles pouvant déclencher des réponses non autorisées, comme l’envoi d’une liste de tous les utilisateurs. 

Parmi les autres méthodes de test de sécurité, citons les tests d’authentification, qui garantissent le bon fonctionnement des mesures de sécurité des identifications comme la biométrie, et les tests d’autorisation, qui garantissent que les utilisateurs ne peuvent accéder qu’aux fonctionnalités pour lesquelles ils disposent des autorisations. 

Des tests de sécurité sont réalisés pendant et après la phase de développement, et de nouvelles fonctionnalités d’intelligence artificielle (IA) ainsi que l’automatisation améliorent la puissance et la précision de ces tests. Les outils de test de sécurité IA peuvent générer automatiquement des tests, scanner le code à la recherche de bugs, analyser les données de performance pour aider à prédire les problèmes et signaler des comportements anormaux, entre autres.

Dans des secteurs tels que la santé et les services financiers, des réglementations, lois et directives existent pour protéger la sécurité, la sûreté et la confidentialité des utilisateurs. Les exemples incluent la loi HIPAA (informations médicales américaines), le RGPD (informations personnelles dans l’UE) et le CCPA (informations personnelles californiennes). 

Les tests de conformité sont des tests qui permettent de s’assurer que l’API est conforme à toutes les lois et directives applicables. Par exemple, le RGPD accorde le « droit à l’oubli », ce qui signifie que les utilisateurs peuvent demander la suppression complète de leurs données dans les meilleurs délais. Les tests de conformité d’une API au RGPD nécessiteraient de s’assurer que cette règle est respectée.

La phase de déploiement concerne le lancement de l’API. Elle a été testée en termes de fonctionnalité, de sécurité et de conformité, et elle est prête à être utilisée. Au cours de la phase de déploiement, l’API passe de l’environnement de test à l’environnement de production. Le déploiement des API comporte plusieurs étapes.

Avant le déploiement, l’équipe doit procéder à un nouvel examen pour s’assurer que l’infrastructure de soutien, la documentation de l’API, l’assistance aux utilisateurs, les stratégies de distribution et de communication et les protocoles de contrôle sont tous achevés et prêts à être mis en œuvre. Cette liste de contrôle peut inclure la mise à l’échelle des serveurs, la configuration des alertes et des notifications, la création d’une page de FAQ, l’envoi d’une annonce aux clients (ou d’une annonce publique) et plus encore.

Le processus de CI/CD, qui signifie intégration et déploiement continus, est un ensemble de pratiques qui automatisent et rationalisent les cycles de développement, de test et de livraison des logiciels. Il s’agit d’une pratique fondamentale dans la méthodologie DevOps. À l’instar des applications logicielles, les API sont également couramment intégrées aux pipelines CI/CD afin de rationaliser et d’automatiser le déploiement, les tests et les mises à jour des API. 

Une passerelle API est une couche logicielle qui fournit un point d’entrée unique permettant aux clients d’accéder à divers services en back-end ou à plusieurs instances d’un service en back-end. Les passerelles API peuvent offrir plusieurs avantages :

• Simplicité : les clients ne doivent suivre qu’une seule URL de service au lieu de plusieurs.
  
  
• Équilibrage de la charge : une entreprise peut distribuer le trafic d’un seul service sur plusieurs instances afin de répartir la charge et d’éviter les goulots d’étranglement au niveau de la performance.
  
  
• Sécurité et gouvernance: une passerelle peut être utilisée pour appliquer des protocoles de sécurité et de gouvernance standardisés à de nombreuses API. 
  
  
• Mise en cache : une passerelle peut contribuer à la mise en cache en stockant les données fréquemment consultées à travers plusieurs services. Cela aide à accélérer les réponses et à améliorer les performances.

Les entreprises diffusent souvent des versions bêta à des utilisateurs sélectionnés afin de tester une API avant de la mettre à la disposition du public. Cela permet à l’entreprise de détecter et de corriger les bugs, de solliciter des commentaires, de mesurer la performance et de promouvoir l’API dans un environnement plus sûr et plus contrôlé.

Une fois la liste de contrôle et les lancements bêta terminés, il est temps de « basculer » et de déployer complètement l’API. Ce processus peut inclure le lancement de stratégies de distribution pour mieux informer les clients internes ou externes sur l’API et encourager son utilisation. Le processus de distribution peut également inclure la publication de guides utilisateur et d’autres actions de sensibilisation du public, la mise à jour d’un site web ou d’un répertoire d’API et l’ajustement des paramètres pour permettre un accès instantané plutôt que d’exiger une authentification privée.

L’un des principaux avantages de la compréhension et de la planification du cycle de vie complet des API est de s’assurer que la surveillance, l’observabilité et la maintenance sont au cœur des préoccupations, dès le départ. Le travail n’est pas terminé au lancement : de nombreuses choses restent à faire.La surveillance des API est un processus continu, conçu pour observer comment une API fonctionne dans le monde réel, en temps réel. 

Les indicateurs clés de surveillance comprennent le temps de réponse, c’est-à-dire le temps nécessaire à l’API pour répondre aux demandes, le taux d’erreur, ou le pourcentage de requêtes qui échouent, le débit et le trafic, ou le nombre de requêtes que l’API peut traiter, ainsi que l’analyse de l’infrastructure, qui mesure la charge et la santé des serveurs.

L’élément de maintenance fait suite aux données collectées par les outils de surveillance. Cette maintenance peut consister à corriger des bugs, à optimiser les performances, voire à ajouter de nouvelles fonctionnalités ou capacités.

Dans notre exemple de CRM, les outils de surveillance peuvent détecter une latence élevée lorsque les données client sont envoyées d’une plateforme à une autre. La phase de maintenance peut résoudre ce problème en réduisant les redondances de code, en ajustant les paramètres de mise en cache ou en déplaçant les serveurs pour les rapprocher des clients qu’ils desservent.

La fin du cycle de vie d’une API est tout aussi importante, dynamique et informative que n’importe quelle autre phase.

La gestion des versions est le processus étendu de maintien de l’efficacité d’une API grâce à des mises à jour, tout au long de sa durée de vie active. La clé de la gestion des versions est de proposer des changements et des améliorations sans interrompre les fonctionnalités existantes pour les utilisateurs habituels. 

Pour les correctifs simples, les mises à jour sont généralement publiées sans appliquer de nouvelle version de l’API, car ces petites modifications sont considérées comme « non perturbatrices ». Toutefois, pour les modifications « perturbatrices », c’est-à-dire qu’une nouvelle version n’est pas rétrocompatible avec la version qu’elle vise à remplacer, il est recommandé d’introduire la modification en tant que nouvelle version.

La communication, à la fois précoce et fréquente, est essentielle à la gestion des versions. Une pratique courante consiste à prendre en charge les versions parallèles : l’ancienne version reste active et fonctionnelle aux côtés de la nouvelle, et les développeurs communiquent les changements pour inciter les utilisateurs à migrer vers la nouvelle version. Une fois que tous ou suffisamment d’utilisateurs ont migré, l’ancienne version peut être désactivée.

Le retrait est la suppression et la désactivation permanentes d’une API. Toutes les API ne sont pas retirées, mais il est courant de remplacer une API. Une API peut être supprimée pour plusieurs raisons :

• Une nouvelle version offre des performances supérieures
• Les besoins en matière de conformité ou de sécurité ne sont plus pris en compte de manière adéquate 
• Des changements commerciaux ou financiers surviennent au sein de l’entreprise
• Incompatibilité avec les logiciels plus récents

Après sa mise hors service, une API ne sera plus fonctionnelle. Certaines étapes peuvent faciliter cette transition.

Le retrait d’une API nécessite une discussion. Est-il nécessaire de retirer l’API et pourquoi ? Quelle sera l’alternative, le cas échéant ? Qui devra être informé de la retraite imminente ?

En règle générale, l’entreprise annonce qu’une API doit être retirée. Cette annonce comprend toutes les informations nécessaires aux utilisateurs de l’API, telles que les raisons de ce changement, la date à laquelle il aura lieu et les mesures que l’utilisateur doit prendre, le cas échéant. 

L’API est alors officiellement considérée comme étant obsolète. À ce stade, l’API reste opérationnelle mais ne recevra plus de nouvelles mises à jour ou fonctionnalités. La période d’obsolescence est conçue pour donner à l’utilisateur le temps et les informations nécessaires pour effectuer les ajustements nécessaires.

Le « jour du coucher du soleil » est celui où l’API publique est complètement désactivée. Les requêtes ne sont alors plus traitées et les clients qui tentent d’atteindre l’API reçoivent un message d’erreur. Il est recommandé de mettre à jour la documentation pour refléter ce changement, et de libérer tout espace serveur ou autre infrastructure utilisée par l’API. 

Un post-mortem sur une API retirée peut être un exercice utile. Les équipes peuvent discuter des leçons apprises tout au long du cycle de vie des API et de la manière dont elles peuvent être appliquées à de futurs projets.