Le manuel de l'API Life Cycle Mixer : qu'est-ce qui se cache dans une seule source de vérité ?

Par : Ariel DiFelice le 9 juin 2023

Dans le bartending, le manuel du mixeur est une source d'informations fiable. Ces livres peuvent contenir des centaines de recettes de cocktails classiques, dont certaines pourraient avoir 100 ans, tandis que d'autres pourraient concerner des boissons qui n'ont fait leur apparition que récemment. Les manuels du mélangeur peuvent également être d'excellentes sources d'inspiration pour de nouvelles recettes encore à tester pour des ajouts passionnants aux offres d'un bar ou d'un restaurant. Cet équilibre entre préserver l'ancien tout en encourageant l'exploration du nouveau peut fournir une leçon précieuse pour le développement d'API dans le monde du logiciel. La "source unique de vérité" d'une API est, à bien des égards, le propre manuel du mélangeur de l'organisation du logiciel. Cela est particulièrement vrai lorsque la bonne approche est adoptée pour garantir que le logiciel reste fonctionnel et performant et propose des expériences qui ravissent les clients et les incitent à revenir pour plus.

Alors que nous pourrions penser à la mixologie et aux mixologues qui pratiquent ce métier comme des termes relativement nouveaux, la première utilisation enregistrée du mot "mixologue" remonte à 1852 et la "mixologie" a suivi peu de temps après.

À quel point le travail, les mentalités et les passions des mixologues et des développeurs et concepteurs d'API sont-ils similaires ? Consultez cette définition d'un mixologue et comptez les similitudes par vous-même :

"Le terme" mixologue "fait référence à quelqu'un qui étudie l'histoire des boissons mélangées, a une riche appréciation des ingrédients et des techniques utilisées et crée régulièrement de nouvelles boissons mélangées innovantes… leur titre de poste implique qu'ils font une partie importante de leur travail dans les coulisses, créant de nouveaux cocktails artisanaux et apportant leur touche de signature aux favoris existants. "

Les meilleurs développeurs, concepteurs et architectes d'API du monde devraient reconnaître une grande partie de ce qui précède dans leur propre travail. Ils ont un profond respect pour leur métier et le perfectionnent toujours davantage. Ils cherchent à comprendre les goûts et les palais de leurs consommateurs. Ils prennent en compte les contributions des autres parties prenantes, ils testent, itèrent et testent à nouveau leurs créations avant de "mettre" ces API en production.

Comme les mixologues et les barmans (si vous les considérez comme deux rôles différents), chaque professionnel tout au long du cycle de vie de l'API doit comprendre les besoins des consommateurs, des clients et de l'entreprise, puis concevoir et développer ses API en conséquence. Une partie essentielle de ce processus est la validation continue et l'adaptation aux exigences du marché.

Les modifications apportées aux API, même mineures, peuvent avoir des effets importants en aval. Et la même chose peut être dite pour les ajustements apportés à une recette de cocktail séculaire, où l'ajout ou la suppression d'un seul trait de ceci ou cela peut complètement changer la saveur d'une boisson… ainsi que l'intérêt des gens pour celle-ci.

Bien qu'il n'y ait pas de taux de modification "standard" des API à prévoir, vous pouvez vous attendre à ce que des modifications soient nécessaires à chaque nouvelle version du logiciel. Cela peut signifier que des modifications sont apportées (et doivent être testées et validées) toutes les quelques semaines, tous les mois ou même tous les jours, en fonction de votre cadence de publication. Il peut également y avoir des modifications ponctuelles, selon les besoins.

Ce qui est crucial pour les équipes, c'est de s'assurer que ces changements ne perturbent pas les fonctionnalités ou les performances d'une API. Pour rendre cela possible, les équipes tirent de plus en plus parti des tests de contrat d'API pour fournir une sorte de filet de sécurité. Cela se présente sous la forme de tests qui valident les modifications par rapport à un "contrat" ​​qui détaille les fonctionnalités d'origine, convenues et, par conséquent, requises d'une API.

La capacité à prévoir les impacts des modifications apportées aux API peut dépendre de la maturité d'une équipe d'ingénieurs et de sa capacité à collaborer entre les services, les fuseaux horaires et les différents niveaux d'expertise technique. Les outils et les directives qui favorisent la normalisation et la collaboration peuvent empêcher les incidents de négliger ou d'être aveugles aux effets négatifs en aval.

Qu'il s'agisse de pouvoir faire confiance à une seule source de vérité pour la version la plus récente d'une API publiée ou à la dernière édition du manuel d'un mélangeur pour des recettes de boissons éprouvées, une documentation claire et concise est essentielle. Mais il ne suffit pas non plus que cette documentation existe simplement.

Il semble que le bon sens - bien que vous ayez probablement travaillé quelque part où ce n'était pas le cas - que la documentation de votre API doive également être facilement accessible, compréhensible et utilisable. Garantir toutes ces choses conduit à une intégration plus fluide et à une expérience de développeur positive et, finalement, à une adoption plus large d'une API fonctionnelle et performante qui répond ou même dépasse les attentes.

La documentation de l'API est souvent le premier point de contact d'un développeur avec une API. Il sert de guide, guidant les développeurs à travers les fonctionnalités, les points de terminaison, les modèles de requête/réponse et les messages d'erreur de l'API. Il fournit également un aperçu de la logique métier sous-jacente et des caractéristiques uniques d'une API.

Une bonne documentation API suit le principe d'une source unique de vérité, ce qui signifie qu'elle doit être complète, à jour et cohérente. Il doit toujours refléter le comportement réel de l'API, réduisant ainsi les conjectures pour les développeurs et minimisant le risque de malentendus et d'erreurs.

Tout comme un mixologue s'appuie sur une recette de cocktail détaillée et précise pour offrir une expérience agréable à un client, les développeurs d'API dépendent d'une bonne documentation pour créer et fournir des API utiles et à valeur ajoutée et des applications puissantes.

Comme un mixologue qui ajuste méticuleusement les ingrédients d'un cocktail ou qui crée de nouveaux cocktails pour répondre aux goûts changeants des clients, les développeurs doivent constamment adapter leurs API pour répondre à l'évolution des demandes du marché, des besoins commerciaux et des normes de l'industrie.

Ceci est réalisé grâce à un puissant mélange d'études de marché, de collaboration, de respect des normes et de gouvernance et de tests méticuleux. Cependant, à mesure que les technologies et les processus de développement, de test et de déploiement de logiciels continuent d'évoluer, l'industrie technologique doit continuer à se former et à affiner ses pratiques.

Avec un état d'esprit axé sur l'apprentissage constant et l'amélioration continue et une source unique fiable de vérité comme guide, les équipes de développement peuvent proposer en toute confiance des expériences d'API exceptionnelles dans chaque version. En fin de compte, l'objectif est de créer des API fiables et faciles à consommer et qui répondent aux besoins uniques du moment, un peu comme la boisson parfaite d'un mixologue.

Classé sous : API, Application Performance Management/Monitoring, Blogs, Culture DevOps, DevOps Practice, Doin' DevOps Tagged With : API, API, CI/CD, développeurs, développement, documentation, SDLC. cycle de vie, logiciel, test