Microservices, API et innovations: la puissance des API

Bonjour à tous!



Aujourd'hui, nous aimerions vous offrir la traduction d'un article de programmation du célèbre Mike Amundsen , l'architecte principal de l'API Academy. Dans ce texte relativement court, Mike explique intelligemment pourquoi vous devez accorder une attention particulière au développement de l'API et comment les API sont correctement exécutées.

Pendant mon temps en tant que professeur à l' Académie API, j'ai eu l'occasion de voyager à travers le monde pour rencontrer des gens incroyables. Ils travaillent sur des projets époustouflants dans diverses entreprises - des jeunes startups aux entreprises mondiales établies. Incroyablement, mais partout où j'étais et avec qui j'ai parlé, de nombreuses idées, astuces et impressions communes ont fait surface dans nos conversations. Les trois plus courants sont les microservices, les API et une culture de l'innovation. Les trois sont introduits pour accélérer la transformation numérique de l'organisation.

Cet article est le deuxième d'une série de trois publications. Ici, je parlerai de ce que nous enseignons dans notre académie API dans le contexte de ces trois tendances puissantes, et décrirai également quelques astuces qui aideront votre entreprise à passer de grands mots à de vraies conversions. Dans un article précédent, j'ai accordé une attention particulière à l'importance des microservices et je me suis concentré sur trois choses que vous pouvez faire aujourd'hui: 1) la transition vers la livraison continue, 2) la mise à disposition de déploiements préparés et 3) la réduction de la file d'attente «en cours de travail» afin de réduire le délai avant que le produit n'atteigne le marché. Ces trois habitudes essentielles aideront votre organisation à tirer pleinement parti des avantages des microservices.

Les API fournissent une livraison multicanal

De nombreuses entreprises utilisent des microservices, essayant d'encapsuler les capacités clés de leur organisation de manière à assurer leur évolutivité et leur fiabilité. Les microservices correspondent à des éléments fonctionnels importants du composant informatique de votre entreprise. Mais ce n'est que la moitié de la bataille. Il est également nécessaire de comprendre comment offrir ces opportunités, afin qu'avec leur aide, il soit pratique de résoudre les défis actuels auxquels votre entreprise est confrontée. C'est là que l'API entre en jeu.

Les API - interfaces de programmation d'applications - jouent le même rôle pour une machine qu'une interface graphique - pour les utilisateurs des systèmes d'information de votre entreprise. Souvent, les API sont utilisées pour mélanger différentes capacités en une solution cohérente et abordable. Par exemple, votre entreprise peut utiliser des services pour traiter les transactions liées aux clients, aux comptes et aux ventes. Chacun de ces services a été soigneusement conçu, programmé, testé, après quoi il a été publié et intégré à l'infrastructure de votre entreprise; Le service fournit des fonctionnalités essentielles à votre entreprise. Une fois que vous devez créer une nouvelle solution pour initier les utilisateurs au cours des choses - et cette solution devrait fonctionner sur une variété d'appareils et de plates-formes. Nous commençons donc à utiliser l'API à pleine capacité.

Une API unique, affinée pour les solutions - par exemple, une API pour familiariser les utilisateurs avec le système - peut être conçue de sorte que les interactions et les flux de tâches les plus importants qui sont critiques au stade d'une telle familiarisation refassent surface. Ici, nous avons besoin d'une API qui vous permet de mélanger divers éléments fonctionnels liés aux clients, aux comptes et aux ventes dans des interfaces utilisateur sûres, puissantes et abordables pour une grande variété de publics cibles au sein de votre entreprise. Par exemple, les vendeurs peuvent se connecter à partir d'un navigateur, les administrateurs de bureau à partir d'applications PC et les clients potentiels à partir de smartphones et de tablettes.

Nous pouvons dire que l'API est une sorte de «colle» qui maintient les éléments du programme ensemble, une couche intermédiaire à travers laquelle vos services internes et les consommateurs externes de services interagissent. L'API est l'outil pour distribuer des fonctionnalités clés de telle manière que les consommateurs de services puissent les utiliser, dont la tâche est de créer des mécanismes importants pour interagir avec l'utilisateur sur une variété de plates-formes matérielles. Ces consommateurs peuvent inclure d'autres équipes travaillant dans votre bureau, des collègues avec lesquels vous communiquez à distance, des partenaires commerciaux clés ou même des employés distants impliqués dans le développement ou la conception côté client.

Design Thinking et API

La plupart des entreprises savent combien il est important de consacrer du temps au développement d'une interface utilisateur pour leurs applications. Parce qu'il est connu qu'un bon design est apprécié par les utilisateurs, augmente la fidélité à la marque et vous permet de promouvoir une nouvelle entreprise. Dans le même temps, une conception d'interface mal conçue peut ennuyer les clients, nuire à la marque, réduire les revenus et sélectionner des opportunités. Il en va de même pour la conception d'API.

Si l'API est mal exécutée, il sera difficile pour les développeurs de la comprendre, car ils peuvent introduire des erreurs dans le système et provoquer des dépenses inutiles pour corriger les bogues et modifier l'infrastructure. Cependant, si l'API a bien fonctionné, il est plus facile pour l'employé de travailler efficacement avec elle. Le temps nécessaire pour créer une solution stable est réduit, l'équipe reçoit même une incitation à émettre des solutions fraîches et innovantes qui aideraient les clients et les collègues. La conception d'API est un domaine de travail si important que Werner Vogels, directeur de la technologie d'Amazon, a même déclaré:

Nous avons immédiatement reconnu que la conception d'une API est une tâche très importante, car nous n'aurons qu'une seule tentative pour la résoudre correctement.

Ce sont des API de haute qualité qui aident à attirer des partenaires dans votre écosystème numérique et à simplifier les transformations internes de votre entreprise. La capacité de passer du temps à tout faire correctement et, à long terme, est une compétence importante que nous retrouvons uniquement auprès des entreprises qui ont appris à utiliser pleinement leurs API.

Conseils de conception d'API essentiels

Il est très important de bien adapter l'API - et il y a plusieurs raisons. Après la publication, il est impossible de restaurer l'API. Lorsque les clients et les structures commerciales clés dépendent de votre API, la modification de la dépendance peut endommager d'autres éléments du système, casser des fonctionnalités importantes et réduire à zéro vos investissements et votre temps passé. Lors de la mise en œuvre du programme API, vous devez garder à l'esprit d'autres choses importantes. Je n'en mentionnerai que quelques-uns.

L'API canonique n'existe pas

C'est une erreur d'essayer «à l'avance» de choisir une conception d'API canonique pour l'ensemble de votre entreprise. Essayer simplement d'implémenter certains objets et modèles de données dans toute l'entreprise, c'est-à-dire essayer de créer une API unique qui prendrait en compte tous les aspects de votre organisation sans exception, maintenant et à l'avenir - il s'agit très probablement d'une impasse. Il est préférable de fournir à vos développeurs des recommandations et d'indiquer des restrictions qui les aideront à éviter les erreurs, à révéler de manière créative et à appliquer les connaissances du domaine pour créer des API incroyables qui séduiront à la fois les collègues et les partenaires.

Processus de mise en œuvre: couper tout ce qui n'est pas nécessaire

Étant donné que l'API n'est qu'une interface, et non une fonctionnalité en tant que telle, vous devez être en mesure de concevoir, implémenter, tester et déployer l'API en quelques jours et semaines, mais pas en mois. Nous savons comment les entreprises tentent de réduire les risques de création d'une API, en veillant à ce que l'API soit pratique à tester à l'avance, à automatiser le processus de publication, afin que les API elles-mêmes soient moins coûteuses et plus faciles à composer.

Concentrez-vous sur l'interaction, pas sur l'intégration

Un autre aspect clé auquel les entreprises qui réussissent peuvent faire face est la capacité d'enseigner aux équipes de développement à intégrer dans l'API la capacité d'interagir avec d'autres éléments déjà au stade de la conception. Ces organisations expliquent comment travailler avec leurs API; par conséquent, ces API sont non seulement faciles à comprendre, mais également facilement liées à d'autres API de cette société. Il est plus important de se concentrer sur une large interaction que de concevoir une intégration étroite et étroite.

Trois choses que vous pouvez faire aujourd'hui

Un tel travail, comme tout changement important, prend du temps. Cependant, il ne faudra pas longtemps pour attendre le succès. Je vais vous parler de trois mesures que j'ai dû observer dans différentes entreprises, que vous pouvez prendre aujourd'hui.

Prenez votre propre pratique API

Un élément clé du succès à long terme de votre programme API est de développer des pratiques de conception d'API spécifiques à la technologie. Assurez-vous qu'un tel programme ne dépendra pas entièrement de la dernière mode de programmation, à l'aide de bibliothèques ou de plates-formes. Pour cela, il est plus pratique de s'appuyer sur le paradigme «première étape - API».

«La première chose est l'API» signifie que nous concevons d'abord l'API, puis seulement réfléchissons aux détails de sa mise en œuvre. Fondamentalement, le composant métier est le même quelle que soit la technologie avec laquelle vous implémentez l'API: SOAP, CRUD, REST, gRPC, GraphQL ou toute autre chose populaire. En fait, un programme bien conçu vous permettra très probablement de formuler des recommandations pertinentes pour différentes piles technologiques, respectivement, en aidant votre équipe et en évaluant les économies possibles, et en gardant des décisions cohérentes sur les futures versions des plateformes.

Nous garantissons de faibles risques lors de la création d'une API

Après avoir conçu l'API de haute qualité, il est temps de la transformer en réalité. Dans le même temps, je recommande de commencer par une esquisse, puis de passer au prototype et au modèle d'assemblage.

Les API de contour sont précisément des «esquisses». Petits «dessins» approximatifs qui aident à donner une idée de la façon dont cette API peut se révéler «au goût et à la couleur» à partir de la position d'un développeur. Une esquisse API doit être réalisée en quelques heures, pas en quelques jours. De plus, sur sa base, un projet doit être obtenu qui peut être montré aux collègues et aux parties prenantes afin que le premier tour de discussion et les premières modifications ne coûtent presque pas de frais. J'aime utiliser le modèle d'API Apiary pour cela. Il utilise un langage de balisage simple qui vous permet de simuler un serveur API fonctionnel en quelques minutes. Un outil spécifique n'est pas si important, la pratique est importante. Les grandes lignes vous aident à faire des recherches à bas prix et commencent seulement à préparer une API complète.

J'ai remarqué que lors du prototypage, des outils comme Swagger / OpenAPI sont populaires. Les prototypes sont des modèles beaucoup plus élaborés de votre produit final. Ils sont similaires aux décors du film. Si vous ne regardez pas de près, vous voyez une scène pratiquement réelle! L'équipe devrait être en mesure de préparer un prototype détaillé en quelques jours seulement. Un tel prototype doit se connecter librement aux instruments de test, aux services de virtualisation et aux autres éléments de la plate-forme afin que vous puissiez observer directement comment il interagit avec votre système. Des prototypes sont nécessaires pour les tester. Ils sont votre dernière ligne de défense avant de devoir dépenser de l'argent pour créer une véritable API fonctionnelle.

Ici, la phase d'assemblage est terminée. Ensuite, nous devons formuler un plan de travail, fixer des délais et commencer à transformer le prototype en produit. Nous avions besoin d'un croquis et d'un prototype pour déterminer les détails, identifier les bugs, etc. Le processus de construction lui-même n'est pas si intéressant. Vous avez juste besoin de montrer le résultat final tous les jours, implémentez pas à pas l'API jusqu'à ce que le travail soit prêt. De nombreuses entreprises s'efforcent de créer une API pas plus de 90 jours.

API de gestion des trois baleines

Enfin, si vous envisagez la situation plus largement qu'au niveau de la conception et de la mise en œuvre d'une API particulière, vous devez adhérer à un programme viable pour travailler avec l'API dans votre organisation et appliquer des recommandations générales pour développer des API qui seront connues de toutes les équipes. Une réglementation claire vous permet de contrôler le développement de l'API dans toute l'entreprise, sans entrer dans une surveillance excessive des détails de mise en œuvre.
Eric Wilde, mon collègue de l'API Academy, souligne l'importance de «gérer le paysage de vos API», c'est-à-dire de réguler trois éléments clés d'un programme d'API: les protocoles, les formats et la terminologie.

La régulation de protocole est une indication claire des protocoles de niveau application qu'une équipe d'API doit prendre en charge lors de la préparation de nouvelles versions. La plupart des entreprises estiment que toutes les nouvelles API doivent prendre en charge HTTP. Certains indiquent également d'autres protocoles facultatifs, tels que MQTT, Thrift et d'autres protocoles binaires. Ici, il est très important d'informer à l'avance toutes les équipes: «Si vous souhaitez garantir l'interopérabilité de vos API à l'avenir, vous devez utiliser ces protocoles.» Pour implémenter cette règle, il est conseillé d'utiliser un pipeline de livraison continue.

La réglementation des formats signifie que vous devez vous mettre d'accord sur les formats dans lesquels les données seront envoyées entre les services. Presque tous les navigateurs attendent une réponse au format HTML - juste comme ça, au niveau de votre API, vous devez décider dans quel format il va interagir avec l'ensemble de l'écosystème. La plupart des entreprises préfèrent des formats simples, tels que JSON, XML ou CSV, mais leurs modèles de message manquent de métadonnées clés, en particulier les noms d'objets, les liens et les formulaires d'entrée - et ils sont nécessaires pour les interactions à long terme. D'un autre côté, je connais également des entreprises qui utilisent des formats plus avancés, par exemple, HAL, Siren et Collection + JSON pour les API HTTP. Pour les interactions binaires entre les services, de nombreuses organisations prennent comme base le protobuf et les formats similaires. Quel que soit le format que vous choisissez, il est important de le vérifier dans votre chaîne de montage, en vous assurant que seules les API pleinement conformes à la réglementation entrent en production.

Le troisième kit de gestion d'API est la terminologie. Dans ce cas, nous parlons de contrôle sur les noms des points de données et des identificateurs d'action utilisés lors de l'échange de messages entre les services. En respectant la terminologie, l'organisation peut avoir aucun doute que les nouveaux services seront normalement acceptés par les services existants. Rappelant le «langage commun» proposé par Eric Evans pour la conception orientée sujet (DDD), je note que la terminologie que vous choisissez est nécessaire pour parler de l'opération commerciale la plus critique. Il devrait être difficile de produire un service en production qui utilise des noms «flambant neufs» pour les champs de données et les identificateurs d'action. Au contraire, les éléments de la chaîne de montage doivent être vérifiés pour la conformité avec la terminologie générale acceptée dans toute l'entreprise, et les API qui abandonnent cette terminologie ne doivent pas entrer en production.

Après avoir appris ces principes: «Tout d'abord - API», «sketch-prototype-assembly» et «three API control kit», votre équipe pourra utiliser ses API à pleine capacité, sans risquer leur stabilité lors de l'exécution.