Les avantages d'une approche API-First pour la création de microservices

Les API constituent le tissu conjonctif des applications cloud natives : le moyen par lequel les microservices des composants d'une application communiquent. À mesure que les applications se développent et évoluent, le nombre de microservices et d’API augmente également. Bien qu’il s’agisse d’un résultat inévitable dans la plupart des cas, cela crée des défis importants pour les é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 en avons parlé dans un article de blog précédent.

Pour tenter de résoudre le problème de la prolifération des API, une organisation peut essayer d’utiliser une approche descendante en mettant en œuvre des outils de découverte et de correction automatisées des API. Bien que cette solution soit efficace à court terme, elle impose souvent une charge excessive aux équipes chargées de créer et d’exploiter les API et les microservices. Ils doivent soit retravailler les microservices et API existants pour résoudre les problèmes de sécurité et de conformité, soit passer par un processus de révision ardu pour obtenir les approbations requises. C’est pourquoi de nombreuses grandes organisations de logiciels adoptent une approche décentralisée qui utilise une gouvernance adaptative pour donner aux développeurs l’autonomie dont ils ont besoin .

Plutôt que de mettre en place des mesures de protection de dernière minute, une approche ascendante du problème s’avère plus efficace à long terme. Les équipes qui créent et exploitent des API pour différents microservices et applications sont les premières à être impliquées et commencent souvent par adopter une approche API-first pour le développement de logiciels dans votre organisation.

Qu'est-ce que API-First ?

Les API existent depuis des décennies. Mais ce ne sont plus simplement des « interfaces de programmation d’applications ». Au cœur des API se trouvent des interfaces de développement. Comme toute interface utilisateur, les API nécessitent une planification, une conception et des tests. API-first consiste à reconnaître et à prioriser l’importance de la connectivité et de la simplicité dans toutes les équipes qui exploitent et utilisent les API. Il donne la priorité à la communication, à la réutilisation et à la fonctionnalité pour les consommateurs d’API, qui sont presque toujours des développeurs.

Il existe de nombreux chemins vers l’API-first , mais une approche axée sur la conception pour le développement de logiciels est l’objectif final pour la plupart des entreprises qui se lancent dans un parcours API-first. En pratique, cette approche signifie que les API sont entièrement définies avant la mise en œuvre. Le travail commence par la conception et la documentation du fonctionnement de l’API. L'équipe s'appuie sur l'artefact résultant, souvent appelé contrat API , pour informer sur la manière dont elle implémente les fonctionnalités de l'application.

Découvrez les techniques de conception pour soutenir une approche API-first du développement logiciel qui est à la fois durable et flexible dans le chapitre 1 de l'eBook Mastering API Architecture d'O'Reilly, avec les compliments de NGINX.

La valeur de l'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 d’applications commencent leur vie en tant que systèmes modulaires et réutilisables. L’adoption d’un modèle de développement logiciel axé sur les API offre des avantages significatifs 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 impacter les équipes travaillant sur d'autres microservices qui dépendent des API des applications. La collaboration est souvent plus facile tout au long du cycle de vie de l’API puisque chaque équipe peut se référer au contrat d’API établi.
• Expérience de développeur améliorée – La conception axée sur l’API donne la priorité à l’expérience du développeur en garantissant qu’une API est logique et bien documentée. Cela crée une expérience transparente pour les développeurs 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 des développeurs d'API<.htmla>.
• Gouvernance et sécurité cohérentes – Les architectes cloud et de plateforme peuvent organiser l’écosystème API de manière cohérente en intégrant des règles de sécurité et de gouvernance lors de la phase de conception de l’API. Cela permet d’éviter les révisions coûteuses nécessaires lorsque des problèmes sont découverts plus tard dans le processus logiciel.
• Amélioration de la qualité des logiciels – La conception préalable des API garantit que les exigences de sécurité et de conformité sont respectées 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 il est moins nécessaire de corriger les failles de sécurité en production, vos équipes d’ingénierie des opérations, de la qualité et de la sécurité ont plus de temps pour travailler directement avec les équipes de développement afin de garantir que les normes de qualité et de sécurité sont respectées dans la phase de conception.
• Mise sur le marché plus rapide – Avec moins de dépendances et un cadre cohérent pour la communication interservices, différentes équipes peuvent créer et améliorer leurs services beaucoup plus efficacement. Une spécification d’API cohérente et lisible par machine est un outil qui peut aider les développeurs et les équipes Platform Ops à mieux travailler ensemble .

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

Comment l’adoption d’une spécification API commune peut aider

Dans le paysage typique des microservices d'entreprise et des API, il y a plus de composants en jeu qu'une équipe Platform Ops ne peut en suivre au quotidien. L’adoption d’une spécification d’API standard et lisible par machine aide les équipes à comprendre, surveiller et prendre des décisions concernant les API actuellement opérationnelles dans leurs environnements.

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 produisant un contrat API et en le formalisant dans une spécification standard, vous pouvez vous assurer que toutes les parties prenantes sont sur la même longueur d'onde quant au fonctionnement d'une API. Cela facilite également le partage de définitions et de capacité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 webhooks
• AsyncAPI – Descriptions JSON ou YAML des API pilotées par événements
• Schéma JSON – Descriptions JSON des objets de schéma utilisés pour les API

Les API REST constituent la majeure partie des API en production aujourd'hui et la spécification OpenAPI est la méthode standard pour écrire une définition d'API pour 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 d'API et de passerelle d'API, notamment NGINX. Le reste de ce blog se concentrera sur la façon dont vous pouvez utiliser la spécification OpenAPI pour réaliser quelques cas d'utilisation importants.

La spécification OpenAPI est un format open source permettant de définir des API au format JSON ou YAML. Vous pouvez inclure une large gamme de caractéristiques d’API, comme illustré par l’exemple d’API simple suivant. Ici, une simple requête HTTP GET renvoie une liste d’articles sur une liste de courses imaginaire.

API ouverte: 3.0.0info :
version : 1.0.0
titre : API de liste d'épicerie
description : Un exemple d'API pour illustrer la spécification OpenAPI

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

chemins :
/liste :
get :
description : Renvoie une liste d'articles sur votre liste de courses 
réponses :
        '200' :
description : Liste renvoyée avec succès
contenu :
schéma :
type : tableau
éléments :
type : objet
propriétés :
nom_élément :
type : chaîne

Les définitions qui suivent la spécification OpenAPI sont à la fois lisibles par l’homme et par la machine. Cela signifie qu'il existe une source unique de vérité qui documente le fonctionnement de chaque API, ce qui est particulièrement important dans les organisations avec de nombreuses équipes créant et exploitant des API. Bien entendu, pour gérer, gouverner et sécuriser les API à grande échelle, vous devez vous assurer que le reste des outils de votre plateforme API (passerelles API, portails de développeurs et sécurité avancée) prennent également en charge la spécification OpenAPI.

Plongez plus en profondeur dans la conception d'API REST à l'aide de la spécification OpenAPI dans le chapitre 1 de Mastering API Architecture .

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

L'utilisation d'une spécification 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 signifie que différents systèmes et clients peuvent consommer et utiliser le contrat API. Cela permet aux équipes Platform Ops d’intégrer, de gérer et de surveiller plus facilement des architectures complexes.
• Documentation cohérente – Le contrat API est documenté dans un format standard, y compris les points de terminaison, les formats de demande et de réponse et d’autres détails pertinents. De nombreux systèmes peuvent utiliser le contrat pour générer une documentation complète, apportant de la clarté et permettant aux développeurs de comprendre plus facilement comment utiliser l'API.
• Meilleurs tests – Les spécifications API peuvent être utilisées pour générer et exécuter automatiquement des tests, ce qui peut aider à garantir que l’implémentation de l’API respecte le contrat et fonctionne comme prévu. Cela peut aider à identifier les problèmes avec une API avant qu'elle ne soit publiée en production.
• Sécurité améliorée – Les outils de sécurité avancés peuvent utiliser la spécification OpenAPI pour analyser le trafic API et le comportement des utilisateurs. Ils peuvent appliquer une sécurité positive<.htmla> en vérifiant que les requêtes API sont conformes aux méthodes, aux points de terminaison et aux paramètres pris en charge par le point de terminaison de l'API. Le trafic non conforme est bloqué par défaut, ce qui réduit le nombre d’appels que vos microservices doivent traiter.
• Évolution plus facile – Les spécifications d’API peuvent faciliter l’évolution du contrat d’API et de l’application elle-même au fil du temps en fournissant un moyen clair et standard de documenter et de communiquer les modifications dans des formats lisibles par machine et par l’homme. Associé à des pratiques de gestion des versions appropriées, cela permet de minimiser les impacts des modifications d'API sur les consommateurs d'API et garantit qu'une API reste rétrocompatible.

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 de logiciels API-First

NGINX fournit 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 API. Avec lui, vous pouvez configurer et gérer les passerelles API et les portails de développeurs. En tant qu'outil API-first, chaque fonction est accessible via l'API REST, ce qui facilite l'automatisation et l'intégration CI/CD pour les équipes DevOps .

En utilisant la spécification OpenAPI, vous pouvez utiliser les produits NGINX pour :

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

Publier des API sur la passerelle API

API Connectivity Manager utilise la spécification OpenAPI pour rationaliser la publication et la gestion des API. Les développeurs d'API peuvent publier des API sur la passerelle 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 en tant que proxys API, qui contiennent toutes les configurations d'entrée, de back-end et de routage dont la passerelle API a besoin pour diriger les demandes d'API entrantes vers le microservice back-end. Vous pouvez utiliser l'API REST pour déployer et gérer des API sous forme de code en créant des scripts d'automatisation CI/CD simples avec des outils comme 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 API pour le portail des développeurs

La gestion de la documentation est souvent un casse-tête pour les équipes API. Mais la documentation obsolète sur les portails des développeurs est également un symptôme majeur 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 de garantir que les consommateurs d'API peuvent toujours trouver ce dont ils ont besoin. Vous pouvez télécharger des fichiers de spécification OpenAPI directement via l'interface utilisateur d'API Connectivity Manager ou l'API REST.

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 la sécurité positive pour protéger les points de terminaison des API

Vous pouvez également utiliser la spécification OpenAPI pour vérifier que les requêtes API adressées à la passerelle API NGINX Plus sont conformes à ce qu'une API prend en charge. 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 sonder vos services back-end à la recherche de vulnérabilités potentielles.

Au moment de la rédaction de cet article, vous ne pouvez pas utiliser API Connectivity Manager pour configurer NGINX App Protect WAF ; cette fonctionnalité sera disponible plus tard en 2023. Vous pouvez cependant utiliser Instance Manager (un autre module de NGINX Management Suite) et la spécification OpenAPI pour écrire des politiques personnalisées pour votre WAF. Pour plus d'informations, consultez la documentation de NGINX App Protect WAF et Instance Manager .

Apprenez-en davantage sur la sécurité des API et la modélisation des menaces, ainsi que sur la manière d’appliquer l’authentification et l’autorisation au niveau de la passerelle API dans le chapitre 7 de Maîtrise de l’architecture des API .

Résumé

Une approche API-first pour la création de microservices et d’applications peut profiter à votre organisation de nombreuses manières. L’alignement des équipes autour de la spécification OpenAPI (ou d’une autre spécification d’API commune lisible par l’homme et par la machine) permet de favoriser 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 approche API-first pour l’exploitation des API est une étape essentielle vers la réalisation de votre stratégie API-first. Avec NGINX, vous pouvez utiliser la spécification OpenAPI pour gérer vos API à grande échelle dans des équipes et des environnements distribués.

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