Les avantages d’une approche API-first pour la création de microservices

Andrew Stiefel

Les API sont le tissu conjonctif des applications cloud natives : elles permettent aux microservices qui composent une application de communiquer entre eux. À mesure que les applications se développent et passent à l’échelle, le nombre de microservices et d’API augmente lui aussi. Bien que cette évolution soit inévitable dans la plupart des cas, elle pose des défis majeurs aux équipes Platform Ops chargées de garantir la fiabilité, l’évolutivité et la sécurité des applications modernes. Nous appelons ce problème la prolifération des API et l’avons abordé dans un précédent article de blog.

Pour tenter dans un premier temps de résoudre le problème de la prolifération des API, une organisation peut opter pour une approche descendante en mettant en œuvre des outils automatisés de détection et de remédiation des API. Si cette méthode est efficace à court terme, elle impose souvent une charge excessive aux équipes chargées de développer et d’exploiter les API et les microservices. Celles-ci doivent soit remanier les microservices et API existants afin de résoudre les problèmes de sécurité et de conformité, soit se soumettre à un processus d’examen fastidieux pour obtenir les approbations requises. C’est pourquoi de nombreuses grandes entreprises du secteur logiciel adoptent une approche décentralisée qui s’appuie sur une gouvernance adaptative afin d’accorder aux développeurs l’autonomie dont ils ont besoin.

Plutôt que de mettre en place des mesures de protection à la dernière minute, une approche ascendante du problème s’avère plus efficace à long terme. Les équipes qui développent et exploitent les API des différents microservices et applications sont les premières à intervenir et commencent souvent par adopter une approche de développement logiciel « API-first » au sein de votre organisation.

Qu’est-ce que l’approche API-first ?

Les API existent depuis des décennies. Mais elles ne sont plus de simples « interfaces de programmation d’applications ». Elles sont avant tout des interfaces destinées aux développeurs. Comme toute interface utilisateur, les API doivent être planifiées, conçues et testées. L’approche API-first consiste à reconnaître et à privilégier l’importance de la connectivité et de la simplicité au sein de toutes les équipes qui exploitent et utilisent des API. Elle donne la priorité à la communication, à la réutilisabilité et aux fonctionnalités destinées aux utilisateurs d’API, qui sont presque toujours des développeurs.

Il existe de nombreuses voies pour adopter une approche API-first, mais pour la plupart des entreprises qui s’engagent dans cette voie, l’objectif ultime est d’adopter une approche du développement logiciel axée sur la conception. En pratique, cette approche implique que les API soient entièrement définies avant leur implémentation. Le travail commence par la conception et la documentation du fonctionnement de l’API. L’équipe s’appuie sur le livrable qui en résulte, souvent appelé « contrat d’API », pour orienter la mise en œuvre des fonctionnalités de l’application.

Découvrez, dans le chapitre 1 de l’e-book Maîtriser l’architecture des API publié par O’Reilly et offert par NGINX, des techniques de conception permettant d’adopter une approche API-first du développement logiciel à la fois pérenne et flexible.

La valeur d’une approche API-first pour les organisations

Une stratégie API-first est souvent idéale pour les architectures de microservices, car elle garantit que les écosystèmes applicatifs sont conçus dès le départ comme des systèmes modulaires et réutilisables. L’adoption d’un modèle de développement logiciel API-first offre des avantages considérables tant aux développeurs qu’aux organisations, notamment :

• Productivité accrue des développeurs – Les équipes de développement peuvent travailler en parallèle et mettre à jour les applications back-end sans perturber les équipes chargées d’autres microservices qui dépendent des API de ces applications. La collaboration est souvent facilitée tout au long du cycle de vie des API, puisque chaque équipe peut se référer au contrat d’API établi.
• Expérience développeur améliorée – La conception API-first donne la priorité à l’expérience développeur en garantissant que l’API est logique et bien documentée. Les développeurs bénéficient ainsi d’une expérience fluide lorsqu’ils interagissent avec une API. Découvrez pourquoi il est si important pour les équipes Platform Ops de prendre en compte l’expérience développeur liée aux API<.htmla>.
• Gouvernance et sécurité cohérentes – Les architectes cloud et plateforme peuvent organiser l’écosystème d’API de manière cohérente en intégrant des règles de sécurité et de gouvernance dès la phase de conception des API. Cela permet d’éviter les révisions coûteuses nécessaires lorsque des problèmes sont découverts plus tard dans le processus de développement logiciel.
• Amélioration de la qualité des logiciels – Concevoir les API en amont permet de répondre aux exigences de sécurité et de conformité dès le début du processus de développement, bien avant que l’API ne soit prête à être déployée en production. Comme elles ont moins de failles de sécurité à corriger en production, vos équipes chargées des opérations, de la qualité et de l’ingénierie de la sécurité disposent de plus de temps pour travailler directement avec les équipes de développement afin de garantir le respect des normes de qualité et de sécurité dès la phase de conception.
• Mise sur le marché plus rapide – Avec moins de dépendances et un cadre cohérent pour la communication entre les services, les différentes équipes peuvent développer et améliorer leurs services beaucoup plus efficacement. Une spécification d’API cohérente et lisible par machine peut notamment aider les développeurs et les équipes chargées des opérations de la plateforme à mieux collaborer.

Dans l’ensemble, l’adoption d’une approche API-first peut aider une entreprise à mettre en place une architecture de microservices plus flexible, évolutive et sécurisée.

Comment l’adoption d’une spécification d’API commune peut être bénéfique

Dans un environnement d’entreprise classique composé de microservices et d’API, le nombre de composants en jeu dépasse ce qu’une équipe chargée des opérations de plateforme peut suivre au quotidien. L’adoption d’une spécification d’API standard et lisible par machine aide les équipes à comprendre et à surveiller les API actuellement en service dans leurs environnements, ainsi qu’à prendre des décisions à leur sujet.

L’adoption d’une spécification d’API commune peut également contribuer à améliorer la collaboration avec les parties prenantes pendant la phase de conception de l’API. En établissant un contrat d’API et en le formalisant dans une spécification standard, vous pouvez vous assurer que toutes les parties prenantes s’accordent sur le fonctionnement de l’API. Cela facilite également le partage de définitions et de fonctionnalités réutilisables entre les équipes.

Il existe aujourd’hui trois spécifications d’API courantes, chacune prenant en charge la plupart des types d’API :

• OpenAPI – descriptions JSON ou YAML de toutes les API web et de tous les webhooks
• AsyncAPI – descriptions JSON ou YAML d’API événementielles
• JSON Schema – descriptions JSON des objets de schéma utilisés pour les API

Les API REST constituent aujourd’hui la majorité des API en production, et la spécification OpenAPI est la norme pour rédiger la définition d’une API REST. Elle fournit un contrat lisible par machine qui décrit le fonctionnement d’une API donnée. La spécification OpenAPI est largement prise en charge par divers outils de gestion des API et de passerelle d’API, notamment NGINX. La suite de cet article explique comment utiliser la spécification OpenAPI pour répondre à plusieurs cas d’usage importants.

La spécification OpenAPI est un format open source permettant de définir des API en JSON ou en YAML. Elle permet d’inclure un large éventail de caractéristiques d’une API, comme l’illustre l’exemple simple suivant. Ici, une simple requête HTTP GET renvoie la liste des articles d’une liste de courses fictive.

openapi: 3.0.0info:
  version: 1.0.0
  title: Grocery List API
  description: An example API to illustrate the OpenAPI Specification

servers:
url: https://api.example.io/v1

paths:
  /list:
    get:
      description: Returns a list of stuff on your grocery list             
      responses:
        '200':
          description: Successfully returned a list
          content:
            schema:
              type: array
              items:
                type: object
                properties:
                   item_name:
                      type: string

Les définitions conformes à la spécification OpenAPI sont lisibles aussi bien par les humains que par les machines. Il existe ainsi une source unique de vérité qui décrit le fonctionnement de chaque API, ce qui est particulièrement important dans les organisations où de nombreuses équipes développent et exploitent des API. Bien entendu, pour gérer, gouverner et sécuriser des API à grande échelle, vous devez vous assurer que les autres outils de votre plateforme d’API – passerelles API, portails pour développeurs et solutions de sécurité avancée – prennent également en charge la spécification OpenAPI.

Découvrez plus en détail comment concevoir des API REST à l’aide de la spécification OpenAPI dans le chapitre 1 de « Maîtriser l’architecture des API ».

Avantages de l’adoption d’une spécification d’API commune

L’utilisation d’une spécification d’API commune, telle que la spécification OpenAPI, présente plusieurs avantages :

• Interopérabilité améliorée – Une spécification commune et lisible par machine permet à différents systèmes et clients d’exploiter et d’utiliser le contrat d’API. Les équipes chargées des opérations de plateforme peuvent ainsi intégrer, gérer et surveiller plus facilement des architectures complexes.
• Documentation cohérente – Le contrat d’API est documenté dans un format standard, notamment les points de terminaison, les formats de requête et de réponse, ainsi que d’autres informations pertinentes. De nombreux systèmes peuvent utiliser ce contrat pour générer une documentation complète et claire, permettant ainsi aux développeurs de comprendre plus facilement comment utiliser l’API.
• Tests améliorés – Les spécifications d’API peuvent être utilisées pour générer et exécuter automatiquement des tests, ce qui permet de vérifier que l’implémentation de l’API respecte le contrat et fonctionne comme prévu. Cela permet d’identifier les problèmes liés à une API avant sa mise en production.
• Sécurité renforcée – Les outils de sécurité avancés peuvent utiliser la spécification OpenAPI pour analyser le trafic de l’API et le comportement des utilisateurs. Ils peuvent appliquer un modèle de sécurité positive<.htmla> en vérifiant que les requêtes adressées à l’API respectent les méthodes, les points de terminaison et les paramètres pris en charge par celle-ci. Le trafic non conforme est bloqué par défaut, ce qui réduit le nombre d’appels que vos microservices doivent traiter.
• Évolution facilitée – Les spécifications d’API peuvent faciliter l’évolution du contrat d’API et de l’application au fil du temps en fournissant un moyen clair et standard de documenter et de communiquer les modifications dans des formats lisibles aussi bien par les machines que par les humains. Associées à de bonnes pratiques de gestion des versions, elles permettent de réduire au minimum l’impact des modifications apportées à l’API sur ses utilisateurs et de garantir sa rétrocompatibilité.

Dans l’ensemble, l’utilisation d’une spécification d’API commune peut contribuer à améliorer l’interopérabilité, la documentation, les tests, la sécurité et l’évolution progressive d’une API.

Comment NGINX prend en charge le développement logiciel axé sur les API

NGINX propose un ensemble d’outils légers et cloud natifs qui facilitent l’exploitation, la surveillance, la gouvernance et la sécurisation des API à grande échelle. Par exemple, API Connectivity Manager, qui fait partie de F5 NGINX Management Suite, fournit un plan de gestion unique pour vos opérations d’API. Il vous permet de configurer et de gérer des passerelles API et des portails pour développeurs. Étant lui-même un outil axé sur les API, toutes ses fonctions sont accessibles via une API REST, ce qui facilite l’automatisation et l’intégration CI/CD pour les équipes DevOps.

Grâce à la spécification OpenAPI, vous pouvez utiliser les produits NGINX pour :

• Publier des API sur la passerelle d’API
• Générer la documentation des API pour le portail des développeurs
• Appliquer une sécurité positive pour protéger les points de terminaison d’API

Utilisez la spécification OpenAPI pour publier une API sur la passerelle d’API et sa documentation sur le portail des développeurs, ainsi que pour définir les politiques de sécurité du WAF via des pipelines CI/CD ou l’interface utilisateur.

Publier des API sur la passerelle d’API

API Connectivity Manager utilise la spécification OpenAPI pour simplifier la publication et la gestion des API. Les développeurs peuvent publier des API sur la passerelle d’API à l’aide de l’interface utilisateur de NGINX Management Suite ou de l’API REST entièrement déclarative. Les API sont ajoutées à la passerelle sous forme de proxys d’API, qui contiennent toutes les configurations d’entrée, de backend et de routage dont la passerelle a besoin pour acheminer les requêtes d’API entrantes vers le microservice backend. Vous pouvez utiliser l’API REST pour déployer et gérer les API sous forme de code en créant de simples scripts d’automatisation CI/CD avec des outils tels qu’Ansible.

Pour obtenir des instructions complètes sur l’utilisation de la spécification OpenAPI pour publier une API, consultez la documentation d’API Connectivity Manager.

Générer la documentation de l’API pour le portail des développeurs

La maintenance de la documentation est souvent un casse-tête pour les équipes chargées des API. Cependant, une documentation obsolète sur les portails des développeurs est également l’un des principaux symptômes de la prolifération des API. API Connectivity Manager utilise la spécification OpenAPI pour générer automatiquement la documentation et la publier 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 peuvent toujours trouver ce dont ils ont besoin. Vous pouvez importer des fichiers de spécification OpenAPI directement depuis l’interface utilisateur ou l’API REST d’API Connectivity Manager.

Pour obtenir des instructions complètes sur la publication de la documentation de l’API sur le portail des développeurs, consultez la documentation d’API Connectivity Manager.

Appliquer une sécurité positive pour protéger les points de terminaison d’API

Vous pouvez également utiliser la spécification OpenAPI pour vérifier que les requêtes adressées à la passerelle d’API NGINX Plus sont conformes aux fonctionnalités prises en charge par l’API. En appliquant une sécurité positive (un modèle de sécurité qui définit ce qui est autorisé et bloque tout le reste), vous pouvez empêcher les requêtes malveillantes de rechercher d’éventuelles vulnérabilités dans vos services backend.

À l’heure où nous écrivons ces lignes, vous ne pouvez pas utiliser API Connectivity Manager pour configurer NGINX App Protect WAF ; cette fonctionnalité sera disponible plus tard en 2023. Vous pouvez toutefois utiliser Instance Manager (un autre module de NGINX Management Suite) et la spécification OpenAPI pour rédiger des politiques personnalisées pour votre WAF. Pour plus d’informations, consultez la documentation de NGINX App Protect WAF et d’Instance Manager.

Pour en savoir plus sur la sécurité des API et la modélisation des menaces, ainsi que sur la mise en œuvre de l’authentification et de l’autorisation au niveau de la passerelle API, consultez le chapitre 7 de l’ouvrage « Mastering API Architecture ».

Résumé

Une approche API-first de la création de microservices et d’applications peut apporter de nombreux avantages à votre organisation. Fédérer les équipes autour de la spécification OpenAPI (ou d’une autre spécification d’API commune, lisible à la fois par les humains et les machines) favorise la collaboration, la communication et les opérations entre les équipes.

Les applications modernes fonctionnent dans des environnements cloud natifs complexes. L’adoption d’outils permettant une gestion des API fondée sur une approche « API-first » constitue une étape essentielle dans la mise en œuvre de votre stratégie « API-first ». Avec NGINX, vous pouvez utiliser la spécification OpenAPI pour gérer vos API à grande échelle au sein d’équipes et d’environnements distribués.

Commencez un essai gratuit de 30 jours de NGINX Management Suite, qui comprend l’accès à API Connectivity Manager, à NGINX Plus en tant que passerelle API et à NGINX App Protect pour sécuriser vos API.

À propos de l’auteur

Andrew Stiefel

Autres articles de Andrew Stiefel