Beaucoup de travail doit être fait pour implémenter l'API. Une planification excessive peut être un gaspillage d'énergie et son absence entraîne des conséquences désastreuses. Dans ce livre, vous recevrez des solutions qui vous permettront d'allouer les ressources nécessaires et d'atteindre le niveau d'efficacité requis dans le temps optimal. Comment équilibrer flexibilité et performances tout en conservant fiabilité et facilité de configuration? Quatre experts de l'API Academy expliquent aux développeurs de logiciels, aux chefs de produit et de projet comment maximiser la valeur de leurs API en gérant les interfaces comme des produits à vie continue.
Le contenu du livre est basé sur nos connaissances collectives (Mehdi Mejuy, Eric Wilde, Ronnie Mitra, Mike Amundsen) au cours de nombreuses années de création, de développement et d'amélioration de l'API - la nôtre et celle des autres. Il expose toute notre expérience. Nous avons identifié deux facteurs clés pour un développement d'API efficace: la nécessité d'une approche orientée produit et la formation de la bonne équipe. Nous avons également identifié trois facteurs importants pour gérer ce travail: le leadership, le développement de produits et le développement de systèmes API.
Ces cinq éléments constituent la base sur laquelle bâtir un programme de gestion d'API réussi. Nous présentons au lecteur tous ces sujets et fournissons des conseils sur la façon de les adapter au contexte de votre organisation.
Extrait. Systèmes API
Avec la fonctionnalité croissante de l'API, il devient de plus en plus important de gérer les programmes de développement afin que les avantages et la valeur de l'ensemble des API de l'organisation se développent au maximum. Vous devez vous rappeler cet équilibre, car le meilleur (ou relativement bon) moyen de fournir un service individuel à l'aide de l'API peut ne pas être si utile du tout si vous le regardez du point de vue de la facilité d'utilisation de ce service dans le cadre d'un système commun.
Les systèmes d'API modernes sont en constante augmentation en termes de nombre total d'API, ainsi que du nombre d'API utilisées par les nouveaux services. Compte tenu de cette augmentation des interdépendances, nous comprenons qu'il serait utile que les développeurs de nouveaux services n'aient pas à comprendre des conceptions d'API complètement différentes et à les appliquer. Les différences peuvent être dramatiques - par exemple, si l'API utilise un style REST ou orienté événement (voir la section Conception de la section Présentation des piliers du chapitre 4) - mais même si les styles correspondent, des différences comme l'utilisation du format JSON peuvent être détectées ou XML.
Du point de vue d'un utilisateur d'API, il serait également utile d'avoir une terminologie commune. Par exemple, si vous utilisez plusieurs API qui fournissent des données utilisateur sous quelque forme que ce soit, ce sera plus facile si elles ont toutes un modèle utilisateur principal (même si elles sont présentées légèrement différemment, il est néanmoins utile d'avoir un modèle commun pour différents services) .
L'idée des avantages de la normalisation indique clairement que plus elle est, mieux c'est. Dans une certaine mesure, c'est le cas, mais en même temps, on sait que la normalisation prend du temps et des ressources, elle ne se résume généralement pas au «seul vrai et meilleur modèle», mais crée simplement un modèle avec lequel tout le monde peut en quelque sorte s'entendre , et donc, en général, cet investissement présente à la fois des risques et des avantages.
Peut-être que l'utilisation d'un format unique pour chaque API ne sera pas la meilleure solution, il est plus raisonnable de choisir parmi les formats existants, par exemple, JSON ou XML. Dans ce cas, les avantages de l'application des normes existantes l'emportent sur les avantages probables de formats uniques. Cependant, il peut être très coûteux de standardiser certains éléments de différents services, par exemple le modèle utilisateur déjà mentionné. Dans ce cas, il est logique de ne pas aller à de telles dépenses injustifiées pour trouver le seul vrai modèle utilisateur et simplement s'arrêter sur le modèle de domaine.
D'une manière générale, idéalement pour chaque service, nous ne voulons pas réinventer la roue lorsqu'elle n'est pas nécessaire, mais réutiliser les éléments de conception qui réduisent le coût des ressources pour créer une conception, sa compréhension et sa mise en œuvre. Si nous pouvons atteindre un tel niveau idéal de réapplication, ou du moins nous en rapprocher, cela permettra aux créateurs de services de se concentrer sur les aspects de la conception sur lesquels il faut se concentrer sans être distraits par des problèmes déjà résolus.
Nous voyons de plus en plus d'organisations faire exactement cela. Mais le plus important dans tout cela est de comprendre et de s'assurer que les manuels des concepteurs sont constamment mis à jour: de nouvelles méthodes sont évaluées et approuvées, les anciennes méthodes sortent de la circulation, et la principale force motrice de ces changements est l'ensemble en constante évolution des méthodes API dans l'organisation.
Il est important de comprendre que le système API est un environnement mobile et en constante évolution, et pour qu'il continue à fonctionner, l'architecture doit suivre le même chemin de développement continu. Ensuite, il devient comme un système à très grande échelle, par exemple Internet, qui, d'une part, fonctionne tout le temps, et d'autre part, est en constante évolution et de nouvelles normes et technologies y apparaissent constamment.
API d'archéologie
Bien que nous voyons maintenant un grand nombre d'organisations qui commencent tout juste à créer des programmes avec des API, il est important de se rappeler que dans toute organisation qui utilise les technologies de l'information, il y a presque certainement certaines API qui sont utilisées depuis longtemps.
Sur la base de la définition, une API est une interface qui permet à deux composants logiciels d'interagir. Si vous limitez la définition à une compréhension moderne de l'API réseau, il s'agit de n'importe quelle interface permettant à deux composants logiciels d'interagir via le réseau.
Dans de nombreuses organisations, de telles interfaces ne sont pas appelées API et ne sont pas conçues pour être réutilisées (rappelez-vous l'histoire de la célèbre charte d'API de Jeff Bezos, que nous avons racontée dans la sous-section Bezos Charter de la section Design Thinking du chapitre 3). Mais le plus souvent, ces interfaces existent, même si elles ont été créées et utilisées pour l'intégration uniquement pour un usage unique (sapant celle-ci l'une des principales propriétés utiles de l'API - la possibilité de réutilisation).
La recherche et l'application de telles proto-API peuvent être utiles car elles montrent où le besoin d'intégration est apparu (même s'il a été créé à l'aide de méthodes qui ne répondaient pas aux objectifs de l'API). Toutes ces proto-API ne doivent pas être remplacées par des API conventionnelles, mais simplement en comprenant l'historique, vous pouvez avoir des idées sur la façon dont le besoin d'intégration a été observé, ce qui a été fait dans ce domaine et où le besoin d'intégration supplémentaire peut apparaître.
API PROTO
Le besoin d'interaction des composants existe dans tous les systèmes complexes constitués de pièces distinctes. Une API est une façon de procéder, mais il en existe de nombreuses autres. Du point de vue de l'API, tout mécanisme utilisé pour l'interaction de composants qui n'est pas une API peut être considéré comme une proto-API. Dans un système idéal, à l'aide de l'API, toutes les interactions des composants sont effectuées sans exception. Si vous vous souvenez de cette image idéale, toute interaction sans l'aide de l'API devient un candidat à la modernisation - à remplacer par une API. Par conséquent, tout mécanisme d'interaction de composants sans l'aide d'une API peut être considéré comme une proto-API.
En général, l'archéologie API peut vous aider à mieux comprendre le système API, même s'il se compose désormais principalement de proto-API. Il fournit un point de départ pour comprendre le besoin d'intégration qui a surgi dans le passé et pour quels investissements d'API vous pouvez mieux résoudre le réseau problématique de nombreuses intégrations d'utilisateurs. Avec l'expérience et au fil du temps, remplacer les intégrations créées avant l'avènement de l'API par des modèles modernes devient de plus en plus facile.
Gestion des API à grande échelle
La gestion des API à grande échelle est l'équilibre entre l'introduction d'une conception commune au niveau du système et la maximisation de la liberté de choix de conception au niveau de l'API individuelle. Le choix entre l'intégration centralisée pour la cohérence et l'optimisation et la décentralisation pour la flexibilité et le développement est un problème courant dans un système complexe.
- L'intégration centralisée nous a apporté l'architecture informatique d'entreprise typique du passé. Le principal moteur a été la standardisation de l'exécution des fonctions afin de les fournir de manière optimale et à moindre coût. Un haut niveau d'intégration simplifie vraiment l'optimisation, mais affecte en même temps la capacité à apporter des modifications et à développer le système final.
- La décentralisation est le contraire. L'exemple le plus accessible et à grande échelle est Internet. La principale force motrice ici est la standardisation de l'accès aux fonctions afin que vous puissiez les fournir de nombreuses manières différentes et en constante évolution. Dans le même temps, les fonctions restent disponibles, car l'accès est basé sur des accords généraux sur l'interaction des fonctions. Le principal objectif de la décentralisation est d'affaiblir la cohérence ( http://bit.ly/2FpcUpf ), c'est-à-dire de faciliter les changements dans les différentes parties du système global sans avoir besoin de changer d'autres parties.
DÉCENTRALISATION ET EXÉCUTION
Si nous avons appris quelque chose des promesses incomplètes de l'époque d'une architecture orientée services basée sur SOAP, alors une exécution soigneusement gérée est un aspect clé de la mise en œuvre des perspectives orientées services. SOAP a rempli la promesse de fournir l'accès aux fonctions, mais n'a pas fait face à la tâche tout aussi importante de gérer correctement l'exécution des fonctions. Ainsi, bien que SOAP soit utile (des fonctions qui n'étaient pas disponibles auparavant apparaissaient comme des services), il ne répondait pas aux besoins d'un environnement plus flexible et évolutif.
La complexité de la gestion du système API consiste à se souvenir de ce problème et à éviter le piège dans lequel SOAP est tombé. SOAP a déclaré que seule la disponibilité des services est importante. Ce fut une première étape importante, mais elle n'a pas permis de faire face à la faible cohérence des fonctions. Les API et, si vous vous concentrez particulièrement sur les techniques d'implémentation et de déploiement, les microservices nous permettent de repenser ce qui est important pour les grands systèmes de service et comment créer des systèmes qui ne tombent pas dans le piège SOAP.
Principe de la plateforme
Beaucoup parlent de plates-formes, discutent des API et des principaux objectifs commerciaux. Cependant, ils peuvent signifier des choses complètement différentes. Il est important de se rappeler: si au niveau de l'entreprise, il semble une bonne idée de créer quelque chose en tant que plate-forme, cela ne signifie pas que c'est ainsi que cela devrait être développé au niveau technique.
Au niveau de l'entreprise, la plate-forme fournit quelque chose sur lequel construire quelque chose, et nous ne pouvons pas aller plus loin que cette formulation plutôt vague. Souvent, l'attrait du concept de «plate-forme» est influencé par deux facteurs principaux.
- Quelle est la couverture de la plateforme? Autrement dit, combien d'utilisateurs peuvent être atteints en créant quelque chose sur cette plate-forme? Ceci est généralement déterminé par le nombre d'utilisateurs ou d'abonnés. Il s'agit souvent du paramètre le plus important, calculé par le nombre total ou en utilisant des facteurs qualitatifs qui déterminent les bons utilisateurs, qui peuvent être couverts à l'aide de cette plateforme.
- Quelles sont les fonctionnalités de cette plateforme? Si vous créez quelque chose dessus, comment cela vous aide-t-il ou vous limite-t-il en termes de revenus? Et est-il également facile de changer de plateforme pour ajouter de nouvelles fonctionnalités, idéalement sans nuire à ses utilisateurs?
Ces paramètres sont très importants pour les entreprises, mais un facteur est souvent oublié: les plates-formes obligent toujours les utilisateurs à respecter certaines restrictions, mais ils le font de différentes manières. Voici quelques exemples.
- Les applications Web peuvent être utilisées par n'importe qui et tout ce qui répond aux normes de réseau de base. Dans le cas le plus simple, il s'agit d'un navigateur moderne avec prise en charge des scripts. Tout le monde peut les créer et y accéder librement, et tout le monde peut les utiliser. Aucun élément central ne contrôle le fonctionnement de la plate-forme Web.
- Les applications sur l'App Store d'Apple sont similaires en apparence aux applications Web, mais sont fournies et utilisées de manières complètement différentes. Ils ne peuvent être téléchargés que sur l'App Store, Apple a donc le droit exclusif de décider quels utilisateurs peuvent installer. De plus, ils ne peuvent être exécutés que sur des appareils iOS, c'est-à-dire qu'Apple a le monopole de la vente d'appareils capables d'utiliser ces applications. Les applications de l'App Store sont créées spécifiquement pour l'environnement iOS, c'est-à-dire que les investissements dans leur création ne sont limités que par cette plateforme. Pour utiliser l'application sur toute autre plate-forme, y compris Internet, elle doit être reproduite dans un environnement de développement différent et même dans un langage de programmation différent, ce qui signifie: le côté client de l'application doit être recréé à partir de zéro.
Vous pouvez appliquer ce modèle à la fois aux systèmes API et à l'idée de créer une plate-forme API pour les applications.
Parfois, la plate-forme API fait référence à un environnement spécifique qui donne accès à l'API. Bientôt, il commence à ressembler légèrement au bus de services d'entreprise traditionnel, où une plate-forme similaire devrait fournir l'infrastructure, et les API deviennent accessibles du fait qu'elles peuvent l'utiliser.
Dans d'autres cas, quand on parle de la plate-forme API, ils signifient un ensemble commun de principes utilisés et fournis par les services. Dans ce cas, si le service fait partie de la plateforme, cela n'a rien à voir avec où et comment l'accès lui est ouvert. Si les services adhèrent aux mêmes principes, protocoles et modèles, ils fournissent des API sur cette plate-forme et font ainsi partie du système d'API.
Le deuxième type de plateforme est plus abstrait, mais en même temps, il a plus de fonctionnalités. Séparant les fonctions exécutées et la manière dont elles le font, il facilite la contribution des utilisateurs à la plate-forme. Il ouvre également de nombreuses voies pour l'innovation, permettant aux applications d'expérimenter les méthodes de mise en œuvre sans compromettre leur capacité à contribuer au système API.
Et encore une fois, prenez Internet comme exemple. Si vous ne regardez que du point de vue de l'API, cela permet beaucoup de changements au fil du temps. Par exemple, un réseau de distribution de contenu (CDN) n'est pas intégré à Internet lui-même. Son existence a été rendue possible en raison de la complexité du contenu Internet et de la flexibilité du navigateur, qui vous permet de générer des pages Web à partir de plusieurs sources prises, éventuellement à des endroits différents. On pourrait soutenir que le potentiel de création d'un CDN existait déjà dans les principes et protocoles des toutes premières pages Web, mais le modèle CDN n'apparaissait que lorsqu'il apparaissait.
C'est cette capacité à s'adapter aux nouvelles tâches qui est requise dans les systèmes API. Nous concevons un système basé sur des principes et des protocoles ouverts et extensibles, mais nous pouvons et voulons le changer si nécessaire. Nous créons également des modèles de support qui aident les applications à résoudre plus efficacement les problèmes, et nous voulons développer ces modèles au fil du temps.
Principes, protocoles et modèles
La principale conclusion de la section précédente: la plate-forme ne devrait pas exiger une manière spécifique de faire quelque chose (répondre à la question «Comment?») Ou un endroit spécifique (répondre à la question «Où?»). Une bonne plate-forme est créée pour le développement continu de l'architecture, c'est-à-dire que l'architecture de la plate-forme (et pas seulement l'architecture du produit) évolue constamment, et que tout n'est pas développé en même temps, de sorte qu'il reste inchangé tout le temps de son existence.
DÉVELOPPEMENT D'ARCHITECTURE CONTINUE
Le développement continu d'architecture est une méthodologie pour le développement continu des principes fondamentaux de l'architecture de produit. Les produits individuels sont créés en utilisant des cadres d'architecture existants, et des rapports sur l'application de ces cadres peuvent améliorer l'architecture du produit, la rendant plus efficace.
Une méthodologie de développement flexible et DevOps sont dédiés à l'amélioration du développement de produits individuels. Ils ne parlent pas de la façon d'améliorer les bases de ce processus afin qu'une architecture système plus efficace soit utile pour l'architecture du produit. Le développement continu se produit lorsque des produits individuels sont créés dans l'environnement de travail d'un système existant. Le système facilite la création de nouveaux produits et aide le système à trouver des domaines à améliorer, créant ainsi une boucle de rétroaction.
Le développement continu de l'architecture se concentre sur le développement d'un cadre qui ne nuit pas aux produits existants et permet la création de combinaisons de produits. Idéalement, les bases de l'architecture évoluent constamment afin d'être compatibles avec les versions précédentes, de sorte que le fonctionnement du système n'est presque pas perturbé.
Pour que le développement continu de l'architecture soit possible, la plate-forme doit être construite sur des principes, des protocoles et des modèles. Nous pouvons illustrer ce point avec une plateforme web. On sait depuis longtemps qu'Internet est incroyablement stable et flexible à la fois. Au cours des 30 dernières années, son architecture de base n'a pas changé, mais, bien sûr, a considérablement évolué. Comment cette claire contradiction est-elle devenue possible? Après tout, d'autres systèmes rencontrent des problèmes beaucoup plus rapidement, évoluant sur des trajectoires moins radicales.
L'une des principales raisons est que rien sur Internet ne montre comment un service particulier est mis en œuvre ou activé. Les services peuvent être implémentés dans n'importe quel langage et, bien sûr, ils changent au fil des ans, car les langages de programmation changent également. Ils sont fournis dans n'importe quel environnement de travail - au début, ce sont les serveurs situés dans les caves, désormais situés sur Internet lui-même, et récemment, le stockage en nuage est également apparu. Les services peuvent être utilisés par n'importe quel programme client - ils ont également changé de façon spectaculaire, passant de simples navigateurs de ligne de commande à des navigateurs graphiques complexes sur les téléphones mobiles modernes. En se concentrant uniquement sur l'interface, qui détermine la façon dont les informations sont reconnues, échangées et démontrées, l'architecture d'Internet s'est révélée mieux adaptée à la croissance naturelle que tout système informatique complexe que nous avons vu. Les raisons en sont étonnamment simples.
- Les principes sont des concepts fondamentaux construits sur la base même de la plateforme. Dans le cas d'Internet, l'un de ces principes est que les ressources sont reconnues par un identificateur de ressource uniforme (URI), puis le protocole de reconnaissance d'URI donne la permission d'interagir avec ces ressources. Ainsi, bien que nous puissions (au moins en théorie) aller sur Internet sans HTTP (et dans un sens, nous évoluons déjà parce que les protocoles changent partout en HTTPS), il est difficile d'imaginer qu'il est possible d'aller sur Internet sans ressources. Les principes sont reflétés dans les styles de l'API, car les styles sont basés sur différents concepts fondamentaux.
- , . (Hypertext Transfer Protocol (HTTP)), (FTP) , WebSockets WebRTC. , , HTTP/2.
- — . , , , . — Oauth, HTTP, — . — . , Oauth, , CDN. , , , , . — , .
, . , , . , -, .
, . . , - , . , , . , , , .
API . , , , , , . API — , , .
API
API . , , . , «» API, , API, .
API .
- API (, / ) . , API RPC — , API REST .
- API . , API HTTP HTTP.
- API . , 200 HTTP ( http://webconcepts.info/concepts/http-header/ ), . API , , .
- API , API ( «» . 188). : API , API, .
, — . , — . , , . , .
API — , .
- , , , , . , .
- , , . , . , , .
. , , , .
« » - - , . XML/JSON. XML-, API JSON ( , , , ).
API API
API , , , API . , . , API! API API: «, API, API».
, , API API (, , API). API API. API ( — «» « API» ), API . , .
, , , , . , API API.
, API API , . , .
. , API . , , - API.
«», «», «» «» . , , . , - , . , . , , , , , . « API» « API» 9 .
, API, API, API .
API , — , . . . — , .
, : , API, API. , , , , , , , API API, API API. API , , .
. , API, , , . , -, .
API API, , , , -. , : , API , , , , .
, API , : API , . : , , API, , .
— API, OAuth.io APIDays — API, . API API, , , API - . API, «API : », 2015 API « ». , - HEC API.
, API . IETF W3C. , , EMC, Siemens CA Technologies.
. API UX , API .
, , , , - . API API , , , API .
»Plus d'informations sur le livre sont disponibles sur
le site Web de l'éditeur»
Contenu»
Extrait25% —
APILors du paiement de la version papier du livre, un livre électronique est envoyé par e-mail.