Qu’est-ce qu’un modèle de maturité API ?

Certains cadres de maturité API mettent l’accent sur des dimensions spécifiques telles que la sécurité, la découvrabilité, la maintenabilité ou l’ingénierie de plateforme. Les fournisseurs de gestion API, dont Kong, Tyk et Curity, proposent des modèles de maturité API alignés sur leurs propres solutions, aidant les clients à évaluer leurs progrès dans l’adoption de ces plateformes. D’autres modèles sont plus vastes et peuvent être appliqués à n’importe quel protocole ou architecture.

Les interfaces de programmation d’application (API), qui facilitent les connexions entre plusieurs services et applications, sont un pilier essentiel de l’Internet, permettant aux développeurs d’utiliser des technologies et des sources de données tierces, plutôt que de devoir les créer de toutes pièces. Elles favorisent également l’intégration des ressources et des données, mais aussi la sécurité et la gouvernance au sein des entreprises, simplifiant les déploiements internes et les communications entre les équipes. Plusieurs API peuvent être regroupées avec des bibliothèques, des outils d’interface utilisateur et d’autres composants pour former un kit de développement logiciel (SDK), un ensemble d’outils qui aide les développeurs à concevoir rapidement et de manière fiable des applications standardisées.

Les modèles de maturité API identifient et décrivent des innovations structurelles et technologiques spécifiques ainsi que des bonnes pratiques stratégiques pouvant aider les entreprises à développer des systèmes API plus sophistiqués et robustes, améliorant l’efficacité, la sécurité et l’interopérabilité. Ils servent de feuille de route qui aide les entreprises à décider quelles innovations privilégier lorsqu’elles accélèrent leur développement d’API.

Le modèle de maturité de Richardson, l’un des cadres des exigences les plus largement cités, évalue l’adhésion d’une API aux principes RESTful selon quatre niveaux de maturité, le niveau le plus élevé représentant un système entièrement RESTful.

En 2000, l’informaticien Roy Fielding a introduit REST, un style architectural qui favorise des fonctionnalités telles qu’une interface uniforme, le découplage client-serveur, l’absence d’état, la possibilité de mise en cache et les systèmes en couches. Ensemble, ces capacités peuvent améliorer l’évolutivité, l’efficacité et la flexibilité au sein des entreprises et contribuer à un Internet plus ouvert, plus résilient et plus sécurisé lorsqu’elles sont mises en œuvre à plus grande échelle. Les itérations modernes utilisent souvent la norme HTTP pour transporter les informations et le format JSON lisible par l’homme pour organiser ces données, bien que d’autres protocoles et formats puissent également être utilisés.

En 2008, l’ingénieur logiciel Leonard Richardson s’est appuyé sur ce cadre pour élaborer un modèle qui identifie les changements techniques spécifiques que les entreprises peuvent mettre en œuvre pour améliorer l’adaptabilité et la résilience de leur conception d’API REST. Le modèle de maturité de Richardson (RMM) « vous encourage à considérer les trois technologies web ; URI, HTTP et hypermédia (également appelé HTML), comme trois technologies individuelles plutôt que comme un ensemble complet », a déclaré Leonard Richardson à IBM Think. Le cadre montre les avantages pratiques de la mise en œuvre progressive de chacune d’elles, « étant donné que nous disposons de ces technologies, elles sont très populaires et largement prises en charge par tous les langages de programmation ».

Le modèle de maturité de Richardson privilégie l’implémentation des ressources : chaque ressource reçoit un URI distinct, conformément aux principes généraux REST, qui recommandent d’attribuer à chaque ressource une identification unique. Le RMM encourage également l’utilisation de documents de réponse, qui capturent l’état actuel d’une API, plutôt que des documents de description qui présentent une description statique et prédéfinie d’une API à un moment donné. Le modèle s’applique généralement aux applications basées sur HTTP, bien qu’en tant que cadre conceptuel, il puisse également être utilisé dans d’autres contextes, tels que les réseaux IdO et les pipelines de données.

Le modèle de maturité de Richardson utilise quatre niveaux pour distinguer différents degrés de maturité, allant d’une architecture ne reposant pas sur RESTful à une architecture entièrement RESTful.

Le niveau zéro représente une conception ne reposant pas sur RESTful, avec un point de terminaison unique (comme « /API ») et une seule commande (généralement POST). Bien que le niveau zéro soit simple à implémenter, il n’utilise pas les fonctionnalités les plus puissantes de HTTP, notamment les verbes, les URI et les codes d’état. En réalité, HTTP est utilisé uniquement comme mécanisme de transport, tous les détails opérationnels étant ajoutés au corps du message lui-même.

Comme les modèles d’appel de procédure à distance (RPC) basés sur XML ont toujours utilisé cette méthode, les critiques l’ont surnommée le « marécage de POX » (plain old XML). L’idée est qu’en l’absence de structure et de délimitations claires entre les services, les fonctions et les données peuvent facilement devenir encombrantes et étroitement couplées. Au niveau zéro, l’API n’a pas la capacité d’identifier ou d’exposer des ressources détectables, ce qui oblige ses consommateurs à savoir à l’avance ce qui est disponible. Les développeurs risquent de rencontrer des difficultés en matière de mise à l’échelle, de gestion des versions et de dépannage, car le point de terminaison unique ne peut pas partager les informations le concernant.

Le niveau un introduit plusieurs URI, chacun capable de représenter une ressource différente. Toutefois, elle continue d’utiliser un seul verbe HTTP, généralement POST. Au lieu d’interagir avec un point de terminaison générique « /api », les clients peuvent désormais appeler des points de terminaison qui correspondent à des ressources spécifiques, par exemple « /products », « /carts » ou « /invoices » dans un contexte de commerce électronique. Toutefois, les clients doivent généralement continuer à transmettre leurs intentions opérationnelles ou leurs actions dans le corps de la requête elle-même, plutôt que d’utiliser un ensemble prédéfini de verbes HTTP.

Cette approche établit des frontières plus claires entre les ressources et réduit les ambiguïtés quant aux ressources disponibles pour les clients. Toutefois, les développeurs peuvent facilement confondre les actions qui peuvent être effectuées car il n’existe pas de format standardisé pour appeler des URI. Ce niveau peut également devenir fastidieux au fil du temps car, en pratique, les développeurs peuvent créer de nouveaux points de terminaison pour des actions individuelles, telles que « /productsUpdate » ou « /productsDelete ». Cette approche peut entraîner une accumulation progressive des URI, ce qui complique les déploiements et la gestion des versions.

Enfin, le modèle rend les développeurs plus dépendants de la documentation externe des API car, bien que les ressources se voient attribuer des URI distincts, elles ne peuvent pas exposer les actions pouvant être interprétées ou réalisées.

Le niveau deux ajoute les méthodes HTTP, un ensemble standardisé de verbes que les développeurs peuvent utiliser pour interagir avec les données et les services. Dans de nombreuses configurations, les clients peuvent utiliser quatre commandes de base ; créer, lire, mettre à jour ou supprimer, pour effectuer différentes actions sur chaque point de terminaison. Les en-têtes peuvent être utilisés pour transmettre des informations supplémentaires telles que le type de contenu, les exigences conditionnelles ou les identifiants d’autorisation lors de l’appel API.

Cette approche est plus efficace et mieux organisée que les niveaux un et zéro, car les utilisateurs ont une idée de ce dont l’API est capable et de la manière dont les clients peuvent interagir avec elle. En revanche, les API ne sont pas en mesure de transmettre ces informations en temps réel. Les utilisateurs ne peuvent connaître chaque API que par l’intermédiaire d’un portail de développement, diminuant la découvrabilité. Cette approche statique peut également conduire à des désalignements si la documentation de l’API ne correspond pas aux capacités actuelles.

Aujourd’hui, les écosystèmes API des entreprises fonctionnent au niveau deux, car ce niveau offre un équilibre entre la prévisibilité, l’efficacité et l’accessibilité. Il permet également aux entreprises de tirer parti des capacités d’infrastructure distinctes du format HTTP, telles que la mise en cache (stockage local des ressources fréquemment utilisées, afin qu’elles puissent être rapidement récupérées), ce qui conduit à des gains de performance significatifs.

Le niveau trois introduit HATEOAS, ou hypermédia, comme moteur de l’état des applications. Lorsqu’un client appelle l’API, celle-ci répond par une liste dynamique d’options pour diverses actions et termes connexes, comme le fonctionnement des navigateurs modernes. Ces actions et ces termes sont transmis suivant une approche in-band, ce qui signifie que les développeurs n’ont pas besoin de consulter une documentation externe pour en prendre connaissance. Les architectures basées sur l’hypermédia favorisent également l’interopérabilité, les clients externes pouvant facilement accéder aux services sans apprendre à les utiliser à l’avance.

Dans le même temps, les contrôles hypermédia introduisent une plus grande complexité lors de l’exécution : « Le client doit pouvoir non seulement réagir de manière préprogrammée, mais aussi lire les documents provenant du serveur et utiliser leur contenu pour décider de sa prochaine requête », souligne Leonard Richardson.

La création et la maintenance de capacités hypermédias peuvent être plus coûteuses et chronophages en raison de la structure dynamique des hypermédias. L’API répond aux requêtes des clients en leur fournissant un ensemble de liens vers d’autres actions, ce qui est plus contraignant sur le plan opérationnel. En outre, de nombreuses plateformes clientes ne prennent pas en charge les hypermédias. Par conséquent, lorsqu’une entreprise adopte HATEOAS, les utilisateurs externes doivent parfois trouver les outils compatibles avant de pouvoir accéder à ces services.

Aujourd’hui, HATEOAS est le plus souvent utilisé par les bibliothèques, les organisations à but non lucratif, les institutions scientifiques, les coalitions commerciales ou les entreprises rebelles (entreprises qui tentent de révolutionner un secteur), explique Leonard Richardson, car il favorise l’ouverture et l’interopérabilité. L’hypermédia peut également être efficace lorsqu’il est utilisé en interne, car il permet aux utilisateurs de découvrir facilement les API et les actions, même s’ils n’ont aucune connaissance préalable de l’écosystème API. Certaines entreprises peuvent proposer des API hypermédias pendant leur phase de croissance, puis en restreindre l’accès lorsqu’elles commencent à monétiser leur produit.

Le secteur s’oriente de plus en plus vers des alternatives telles que GraphQL et gRPC pour des cas d’utilisation particuliers. Alors que 93 % des développeurs déclarent utiliser des services web RESTful d’une manière ou d’une autre, selon le rapport State of the API de Postman, un tiers d’entre eux utilisent désormais GraphQL, alors que 14 % utilisent gRPC. GraphQL peut récupérer intelligemment les requêtes de plusieurs microservices, même de services hébergés dans des environnements différents, et les compiler en une seule réponse, ce qui accroît l’efficacité et évite le surprovisionnement ou le sous-provisionnement. gRPC, quant à lui, est idéal pour le streaming, la télémétrie et d’autres cas d’utilisation où des performances élevées et une faible latence sont des préoccupations majeures.

Bien que GraphQL et gRPC ne puissent pas reproduire la nature dynamique de l’hypermédia, les deux architectures abordent avec plus de précision les difficultés liées à l’efficacité et à la gestion des schémas, ce qui conduit certaines entreprises à privilégier ces implémentations au détriment des contrôles hypermédias complets.

Dans le modèle de maturité de Richardson, le passage d’un niveau de maturité d’API à un autre peut présenter des défis techniques et de conception. Le processus implique souvent de redéfinir le code serveur pour prendre en charge plusieurs URI (niveau un) et plusieurs méthodes HTTP (niveau deux), en mettant à jour les règles de routage, les interactions avec les bases de données, les tests, la documentation et les contrôleurs.

Les entreprises peuvent commencer par répertorier leurs points de terminaison actuels, identifier ceux qui peuvent être modifiés pour respecter les contraintes RESTful et cartographier les ressources et les verbes nécessaires. Les développeurs peuvent créer une nouvelle version en plus de la version actuelle de l’entreprise afin que les appels des clients ne soient pas interrompus pendant la transition. Un ensemble complet de codes d’erreur peut également aider les utilisateurs à apprendre à maîtriser les nouveaux points de terminaison de l’API et à résoudre les erreurs sans avoir à consulter une documentation trop volumineuse.

Alors que le RMM se concentre sur des implémentations technologiques spécifiques dans les systèmes RESTful, les modèles organisationnels ont une vision plus large, aidant les entreprises à s’aligner sur un ensemble de principes partagés qui favorisent la cohérence, l’optimisation des ressources et l’adaptabilité. Bien que les cadres de maturité stratégique puissent varier d’une entreprise à l’autre, une approche commune intègre quatre niveaux :

Dans les écosystèmes API basiques ou ad hoc, les entreprises réagissent aux préoccupations immédiates plutôt que de travailler sous un cadre cohérent de développement d’API. Les développeurs créent et retirent des API selon les besoins avec un contrôle centralisé limité, ce qui peut entraîner des désalignements et des problèmes de gouvernance, de sécurité et d’observabilité. Avec peu d’informations sur les performances actuelles des API, les équipes ne peuvent pas allouer les ressources ou planifier l’avenir de manière efficace.

Les écosystèmes API normalisés introduisent une documentation cohérente, des conventions de dénomination, des codes d’erreur et des modèles de conception. Une passerelle API peut être utilisée pour renforcer l’authentification, l’autorisation et d’autres protocoles de sécurité des API centralisés. Les développeurs peuvent ajouter, supprimer et maintenir des API en toute confiance dans la structure de gouvernance de l’entreprise, tout en réutilisant et adaptant facilement les composants. Les clients peuvent facilement découvrir et en savoir plus sur les services disponibles grâce à un portail de développement et à une présentation intégrée, améliorant l’adoption globale des API.

Le problème ? Il existe peu de mécanismes permettant d’évaluer les performances et la sécurité des API à ce stade, c’est pourquoi les équipes peuvent avoir du mal à maintenir le contrôle de l’écosystème. Ainsi, une entreprise peut ne pas être au courant des violations de sécurité, des erreurs de version ou des problèmes d’authentification au sein d’un cluster d’API particulier.

Les cadres gérés utilisent des données de télémétrie, des KPI et d’autres indicateurs pour capturer la performance des API de manière plus détaillée. Par exemple, un système de surveillance peut alerter les développeurs lorsque les clients rencontrent des temps d’arrêt excessifs et aider à identifier le problème sous-jacent, qu’il s’agisse de surcharge de serveur, de coupures réseau, de désalignements de code ou d’autres problèmes.

Les écosystèmes gérés peuvent également proposer une infrastructure de gouvernance des API plus avancée, qui préserve l’autonomie des équipes tout en permettant aux parties prenantes de bien comprendre les API qu’elles sont chargées de gérer. Enfin, les écosystèmes gérés introduisent des processus officiels de gestion du cycle de vie, où les API sont surveillées tout au long des processus de conception, de développement, de maintenance, de gestion des versions et de mise hors service. Toutefois, à ce niveau, les entreprises peuvent encore manquer d’une vision cohérente quant à la façon dont la gestion des API contribue aux objectifs commerciaux plus larges.

Les cadres optimisés ou stratégiques combinent gouvernance, standardisation, gestion du cycle de vie, indicateurs et bonnes pratiques de sécurité avec une planification opérationnelle à long terme. En contrôlant l’ensemble du réseau, les entreprises peuvent dimensionner et allouer efficacement leurs ressources, puis répondre de manière dynamique à l’évolution des conditions du marché. Plutôt que de considérer les API uniquement comme des composants techniques, les entreprises peuvent les déployer au service d’objectifs commerciaux plus larges. Les cadres stratégiques aident les entreprises à élaborer des feuilles de route et des stratégies de planification tournées vers l’avenir, ce qui leur permet d’accélérer l’innovation et d’améliorer leur efficacité opérationnelle.

Les entreprises peuvent élaborer des modèles de maturité API pour répondre à des points sensibles spécifiques ou à des priorités opérationnelles. Les domaines d’intervention les plus courants sont les suivants :

Ces modèles de maturité se concentrent sur les principes de conception d’API tels que l’adoption de protocoles, de pratiques et de normes spécifiques qui contribuent à améliorer l’expérience utilisateur. Le RMM est un exemple de cadre basé sur la conception, mais d’autres modèles peuvent se concentrer sur GraphQL, gRPC et d’autres styles architecturaux.

Les modèles de gouvernance se concentrent sur la mesure dans laquelle les entreprises peuvent garder le contrôle et gérer la supervision de leurs écosystèmes d’API. Aux niveaux les plus élevés, les entreprises maintiennent un niveau élevé de conformité, de qualité des données et de sécurité tout en préservant l’autonomie des parties prenantes.

Les cadres fondés sur la gouvernance prennent également en compte la qualité des mécanismes d’application d’un écosystème API, notamment l’intégration de contrôles automatisés et de processus de validation. Les modèles de propriété, quant à eux, attribuent les API à des équipes spécifiques afin que chaque API soit prise en compte.

Les cadres de maturité axés sur la sécurité évaluent le respect des bonnes pratiques en matière de sécurité. Aux premiers stades, les entreprises peuvent s’appuyer sur des clés API ou une authentification HTTP basique, qui manquent de contrôle granulaire et sont vulnérables à l’exposition. Les systèmes avancés peuvent introduire une authentification et une autorisation basées sur des tokens, ainsi qu’un accès Zero Trust. Les cadres les plus sophistiqués adhèrent aux principes de gestion des identités et des accès, comme l’utilisation des protocoles d’autorisation OAuth et OpenID Connect (OIDC).

Les documents relatifs aux API sont des guides techniques qui fournissent des instructions sur la manière dont les développeurs peuvent utiliser et intégrer une API particulière. La documentation peut inclure des tutoriels et des exemples de code ainsi que des notes de version et des paramètres d’appel acceptables.

Au départ, les entreprises peuvent ne pas disposer de processus standardisés pour créer et maintenir la documentation, ce qui donne peu d’informations aux développeurs sur les capacités de chaque API. Les niveaux supérieurs peuvent introduire des formats standardisés pour décrire les spécifications des API, comme la spécification OpenAPI (OAS) ou le schéma directeur API Blueprint. Les cadres matures peuvent également intégrer l’automatisation, ce qui permet de s’assurer que la documentation est automatiquement mise à jour lors de chaque déploiement.

Les modèles de maturité axés sur l’observabilité aident les entreprises à suivre la sophistication de leurs mécanismes de collecte de données sur l’ensemble des microservices. Les systèmes basiques peuvent utiliser la télémétrie et les indicateurs pour aider les entreprises à détecter les erreurs, mais ne parviennent pas à identifier les tendances de données à long terme.

Les plateformes plus complexes peuvent suivre de manière proactive la latence, les taux de requêtes et d’autres indicateurs pour aider les entreprises à répondre à l’avance aux temps d’arrêt, aux désalignements et aux autres problèmes. Au niveau le plus élevé, les entreprises peuvent identifier des modèles de données de haut niveau et générer des informations exploitables qui orientent le développement futur de l’API.