Gestion des produits API 101

1. Introduction: Bonjour à tous, j'arrive. Je suis chef de produit basé au Royaume-Uni. De tous les produits gérés dans ma carrière. Le plus difficile d'entre eux a été les produits API. De plus en plus d'entreprises commencent à considérer les API comme des produits. Par exemple, si vous visitez une entreprise dans le monde, que ce soit PayPal Stripe, Facebook, Twitter ou toute autre entreprise. Vous trouverez des règles pour les produits API ou les responsables produits expérimentés par les développeurs. Mais comment vous préparez-vous à ces rôles ? Ce qui a été difficile pour moi début, c'est le manque de ressources centralisées qui parlait API spécifiquement destinées aux chefs de produits. Maintenant, ce cours, j'essaie de simplifier les API et de les rendre plus compréhensibles pour tous ceux qui débutent récemment dans le monde des API et de la gestion des produits. Comment, comment j'ai structuré ce cours ? Nous commencerons par comprendre quelques exemples de produits API. Ensuite, nous aborderons les fondamentaux des API. Comment fonctionnent vraiment les API ? Quelle est la technologie derrière les API ? Nous examinerons également un exemple d' utilisation d'une API et via Postman. Ensuite, nous aborderons la gestion de produits d'une API. Comment entrer dans l'état d'esprit des produits API. Quel est le cycle de vie d'une API ? Comment construire, mesurer et développer des produits API. Ensuite, nous aborderons les rôles et les responsabilités de l'équipe API ainsi que du chef de produit API. Enfin, nous examinerons le modèle économique. Comment les API devraient-elles être tarifées ? Quelles sont les différentes options tarifaires disponibles pour nous ? J'espère qu'à la fin de ce cours, vous aurez une assez bonne compréhension de ce que sont les API, pourquoi elles devraient être envisagées comme des produits et comment les gérer en tant que produits. Merci d'avoir écouté et j'espère vous voir de l'autre côté. 2. L'affaire pour les produits API: Salut tout le monde. J'espère maintenant que vous aurez une compréhension assez juste de ce qu'est une API et de ce que la technologie informatique derrière elle, et quels sont les différents types d'API et ainsi de suite. Regardons maintenant le cas d'un produit API. Pourquoi devriez-vous commencer à regarder les API en tant que produit dès le début, car l'industrie du logiciel évoluait traditionnellement des applications et construisait une application de règles standard. Vous avez peut-être un système pour les ressources humaines. Vous avez peut-être un système de gestion de la paie. Vous disposez peut-être d'un système de gestion des ventes. Vous avez peut-être un système de gestion du marketing et ainsi de suite. Donc, chacun de ces systèmes où les applications étaient essentiellement cloisonnées, mais finalement il était nécessaire que ces applications se parlent les uns avec les autres, et donc, des interfaces étaient en cours de développement. Et puis les équipes ont réalisé qu'au lieu de construire les applications d'abord, puis de penser aux interfaces plus tard, elles devraient commencer par une approche API d'abord, nous allons essayer de construire des microservices qui peuvent être consommés par d'autres applications et ainsi de suite. Par conséquent, vous aviez des API privées où les différentes équipes au sein de l'entreprise consomment ces API afin que les systèmes puissent demander facilement des informations à d'autres applications. Maintenant, finalement, les entreprises plus intelligentes ont compris que les API sont beaucoup plus que les leurs. Et les API peuvent être considérées comme des produits eux-mêmes. Par exemple, vous pouvez utiliser votre Google Maps comme application autonome dans votre navigateur ou votre téléphone mobile. Cependant, Google a également une API, Maps API, qui est disponible pour les développeurs publics peuvent utiliser cette carte à l'API, puis créer des produits innovants autour d'eux. Par exemple, vos applications de covoiturage comme Uber et Ola ont utilisé l'API Google Maps pour offrir des expériences client intuitives. Un autre bon exemple est PayPal. Vous pouvez utiliser PayPal pour envoyer de l'argent, recevoir des paiements, etc. Mais les gens ont également API que les entreprises peuvent utiliser pour intégrer les paiements PayPal dans leur site Web à l'aide laquelle les utilisateurs peuvent commencer à acheter le côté gauche. Et PayPal fait beaucoup d'argent grâce à ces API elles-mêmes. dit que des entreprises comme Expedia réalisent au moins 90 pour cent du chiffre d'affaires uniquement des API. Ebay a décidé de réaliser environ 60 pour cent de ses revenus à partir des API. API doivent donc être considérées comme des produits en soi où vous comprenez les besoins spécifiques du client et créez des API qui peuvent servir ce parcours client. C' est donc là que les API doivent être considérées comme des produits. Et la gestion des produits APA entre en scène. Merci d'avoir écouté et j'espère vous voir dans la prochaine classe. 3. Exemples de produits API: Salut tout le monde et bienvenue dans cette classe et tirer, Je veux vous donner un aperçu rapide de ce qui est un produit API. Je ne ferai pas cela en vous montrant quelques exemples de produit API populaire. Et évidemment, nous allons parler de la technologie derrière l'API. Qu' est-ce qu'une API et comment fonctionne-t-elle ? Et qu'est-ce que la gestion des produits API et ainsi de suite dans les classes à venir. Mais avant d'entrer dans les détails de cela, je pense qu'il est important pour nous tous d'avoir une compréhension commune de ce qu'est un produit API. Alors regardons PayPal par exemple. Alors, qu'est-ce que PayPal ? Paypal est un produit qui nous aide à effectuer des paiements ou à recevoir des paiements de quelqu'un. Ils ont donc un beau produit basé sur l'interface utilisateur que beaucoup d'entre vous auraient pu utiliser. Avoir également des API. Donc ils fournissent, pour qu'elle regarde leur site web. Il y a une section appelée développeur, et si vous cliquez dessus, qui fournit toutes les API que développeurs tiers peuvent utiliser pour intégrer dans payant, payant. Donc, si vous cliquez, il a donc de la documentation pour les différentes API. Et si vous cliquez sur API, vous pouvez regarder quelles sont les différentes API sur comment, comment vous connectez-vous réellement au tableau de bord ? Comment obtenir les informations d'identification pour accéder au jeton ? Comment faire les appels d'API ? Ils ont un sandbox, essentiellement c'est un environnement de test où vous pouvez tester l'API et ils ont quelques exemples. Donc, tout cela est destiné à aider les développeurs tiers à mieux comprendre les API, les capacités des API, puis à commencer à consommer les API. C' est donc un exemple. L' autre grand exemple est Twilio. Twilio est très connu pour ses produits basés sur l'API. Encore une fois, toute application populaire produit Pablo que vous voyez ces jours-ci aurait une section spécifiquement destinée aux développeurs. Et Twilio a également une section pour Delta Force et il a quelques-unes de ses API populaires. Par exemple, il a une API WhatsApp. Cliquons et voyons ce qu'il a réellement. Encore une fois, c'est une documentation. Il a clairement dit comment vous commencez en tant que développeur ? Comment pouvez-vous commencer avec cette API ? Quelle est la référence, quels sont les guides et tutoriels pour commencer à utiliser cette API ? Et cela nous aide essentiellement à commencer à consommer l'API facilement. De même, ils ont plusieurs produits qui ont tous été exposés en tant qu'API. Ils ont également des kits de développement de logiciels. Encore une fois, ce sont des bibliothèques que vous pourriez facilement utiliser et commencer à construire les applications en tant que développeur. Et seulement ils ont des kits de développement séparés pour Android, iOS, et ainsi de suite. Alors continuons et regardons l'API de Google. Ainsi, comme vous le savez peut-être, Google Maps, par exemple, est un produit que tout le monde peut utiliser gratuitement. Ainsi, vous installez l'application sur votre téléphone ou vous pouvez ouvrir l'application Google Maps dans votre navigateur, puis commencer à utiliser l'application Maps. Cependant, Google fournit également une API permettant aux développeurs tiers de commencer à les utiliser. Par exemple, les applications de covoiturage comme Ola, Uber utilisent l'API Google Maps pour fournir l'intégration de Maps dans le cadre de leur propre application. Ainsi, tout le monde peut commencer à utiliser cet indicateur de performance clé. Donc, ils ont un site Web appelé développeurs dot google.com. Ensuite, cela est spécifiquement destiné aux développeurs. Nous voulons utiliser le cas d'utilisation spécifique des produits Google. Et maintenant regardons la documentation ici. Et encore une fois, cela nous indique également à quel point vous pouvez commencer à utiliser l'API. Comment programmez-vous votre projet ? Comment activer l'API ou le SDK ? Comment obtenez-vous la clé API, et ainsi de suite et ainsi de suite. Et puis ils disent aussi comment, comment choisir une API. Donc, si vous voulez ajouter une carte à une application Android, alors vous utilisez le SDK Maps pour Android. De même, ils ont différents cas d'utilisation et les API spécifiques que vous pouvez réellement utiliser pour ces différents cas d'utilisation. Regardons également une API spécifique et d, d, disons que vous avez l'API Roads. Regardons l'API la plus proche. Il s'agit donc d'un point de terminaison d'API et des routes les plus proches de cette API, c'est le point de terminaison que vous atteindrez. Ce sont les paramètres de requête que vous utiliserez pour filtrer vos résultats en fonction de vos besoins. Et c'est la clé API que vous allez envoyer. C' est donc l'API spécifique que vous allez utiliser. Et cette documentation nous dit quels sont les différents exemples. Si vous vouliez l'utiliser via Java, Python, Ruby, Go et les facteurs et ainsi de suite, peut également exécuter cela dans les facteurs, qui est une application très populaire pour tester vos API. Nous verrons comment faire cela dans les cours ultérieurs. Donc, c'est à quoi ressemble la réponse et ainsi de suite. Donc, essentiellement, ce que nous avons vu sur ces trois produits différents, c'est que même si chacune de ces entreprises a des produits très réussis en elles-mêmes, elles prennent également beaucoup de soin pour exposer les API à des développeurs tiers. Par conséquent, ces entreprises auraient souvent des responsables de produits dédiés qui gèrent ces expériences autour de ces API. Parce que les développeurs qui vont utiliser cette API sont les vrais utilisateurs de ce produit. Les responsables de produits doivent vraiment comprendre ce que les développeurs veulent ? Quels sont leurs points de douleur ? Quels sont les cas d'utilisation spécifiques pour lesquels ils pourraient utiliser une API ? Construit pas, et pas seulement construire des API, mais aussi construire l'expérience du développeur et l'objet. Essentiellement, à venir avec de la documentation , à trouver des exemples, à venir avec des environnements sandbox, viennent essentiellement avec tous les détails de support pour aider les développeurs à se lancer et à fonctionner rapidement. C' est donc ce qu'est le produit API. Essentiellement, ce n'est pas seulement l'API, mais aussi l'expérience du développeur autour d'elle. Espérons que cela vous donne une assez bonne compréhension de ce que sont les produits api. Ne vous inquiétez pas si vous n'êtes toujours pas entièrement confiant. Ne vous inquiétez pas si vous ressentez encore un peu quand nous avançons dans le cours. Vous auriez donc une bien meilleure compréhension des API et de la gestion des produits API. Merci d'avoir écouté et j'espère vous voir dans la prochaine classe. 4. Quoi qu'il est nécessaire de savoir sur les APIs: En tant que chef de produit, vous allez être invariablement impliqué dans l'utilisation des API d'une vraie mère. Voici les trois scénarios différents dans lesquels vous pourriez être impliqué dans l'utilisation des API. Tout d'abord, vous pourriez avoir affaire à des API internes que différentes équipes de votre organisation utilisent pour des cas d'utilisation partagés. Deuxièmement, vous pouvez utiliser une API tierce dans le cadre de votre expérience produit. Par exemple, si vous êtes un responsable produit Uber, vous pouvez utiliser l'API Google Maps pour vos propres cas d'utilisation. Troisièmement, si vous êtes un gestionnaire de produit Google, vous pouvez exposer une API Maps afin qu'elle puisse être consommée par développeurs tiers comme Uber afin d'utiliser ses propres cas d'utilisation. Il est donc important pour les responsables de produits de mieux comprendre les API. De plus en plus d'entreprises considèrent les API comme des produits et sont constamment à la recherche de gestionnaires de produits API. Alors, qu'est-ce que vous devez vraiment savoir sur les API ? Tout d'abord, vous devez connaître la requête et la réponse à diverses méthodes HTTP. Le point final, quels éléments constituent un message ? Qu' est-ce qu'un en-tête, qu'est-ce que l'authentification ? Qu' est-ce qu'une charge utile ? Qu' est-ce qu'une API RESTful, et ainsi de suite. Donc, dans les conférences à venir, nous allons examiner exactement cela de sorte que d'ici la fin de cette section, vous aurez une assez bonne compréhension d'une API. Merci d'avoir écouté et j'espère vous voir dans la prochaine classe. 5. Qu'est-ce qu'une API: Commençons par la question fondamentale. Qu'est-ce qu'une API ? Api signifie interface de programmation d'application. Et dans sa forme la plus simple, c'est essentiellement une technologie qui aide à se connecter à différents systèmes. Et l'API rend la vie des développeurs plus simple et plus facile. Il, il les aide à se connecter à un système tiers et à utiliser leurs fonctionnalités. Au lieu de construire la fonctionnalité à partir de zéro, il aide les entreprises à se lancer plus rapidement sur le marché. Il aide les entreprises à tirer parti des services existants et ainsi de suite. L' exemple très populaire que j'ai cité plus tôt est l'utilisation d'applications de covoiturage. Et des applications de covoiturage. Vous avez besoin de cartes pour aider les écrivains, ainsi que les consommateurs, facilement savoir où une façon particulière couleurs et comment atteindre une destination un certain temps. Et par conséquent, au lieu de construire une application de cartes à partir de zéro, ils consomment API d'un fournisseur tiers, par exemple, Google, afin qu'ils puissent utiliser l'application Maps fait partie du parcours utilisateur existant. Merci d'avoir écouté et j'espère vous voir dans la prochaine classe. 6. Comment fonctionne les APIs: Alors, comment fonctionnent les API ? Une analogie populaire qui est utilisée pour expliquer les API est l'analogie des restaurants. Disons que vous avez faim, que vous allez dans un restaurant et que vous voulez commander votre nourriture préférée. Vous commencez donc à regarder le menu pour les différentes options disponibles. Ensuite, vous choisissez une option spécifique dont vous avez vraiment besoin. La demande de. Le plus grand, le serveur va ensuite au backend, dit votre demande à la cuisine, et la cuisine traite toute votre nourriture, puis il le rend au serveur, qui vient ensuite et vous donne la nourriture et vous êtes heureux et commencez à manger. Apis, en un sens, fonctionne sur la base de cette architecture de demande et de réponse. Donc, si vous voulez voir votre vidéo préférée, que faites-vous ? Vous allez sur YouTube et demandez à YouTube de lire votre vidéo préférée. Youtube retourne ensuite à la base de données, récupère la vidéo que vous avez réellement demandée et répond à vous avec cette vidéo. Donc, il y a une demande et une réponse dans l'analogie du restaurant, un menu est égal à la documentation de l'API qui vous indique clairement de quoi l'API est capable. Ensuite, la demande est ce que vous donnez au système, puis la réponse du plus grand est égale à la réponse de YouTube. Donc essentiellement, à son niveau fondamental et API consiste en une requête et une réponse. Que contient chaque requête et que contient chaque réponse ? Qu' allez-vous regarder dans les conférences à venir ? Merci d'avoir écouté. 7. Qu'est-ce que les services Web: Maintenant, si vous avez entendu parler des API, vous avez peut-être également entendu parler des services Web. Que sont les services Web ? Sont-ils différents des API ? Regardons les. Maintenant, le service Web est une API à laquelle vous pouvez accéder via Internet. Mais une API peut aussi être une interface entre deux systèmes qui ne sont pas connectés sur Internet. Tous les services Web ou API, mais toutes les API ne doivent pas nécessairement être des services Web. Maintenant, en ce qui concerne les services Web, il existe plusieurs types de services Web différents. Soap, JSON, RPC, XML, API RESTful RPC. Maintenant, au lieu de regarder tous ces différents services en détail, ce que je préfère faire est de me concentrer sur l'API RESTful parce que c'est plus commun et c'est quelque chose que vous auriez entendu encore et encore. Et si vous comprenez vraiment l'API RESTful, vous seriez probablement en mesure de ramasser n'importe quel type d' API à l'avenir aussi facilement dans les classes suivantes, Regardons l'API RESTful plus en détail. 8. Qu'est-ce qu'une API REST: Regardons maintenant ce qu'est une API RESTful. Maintenant, le repos est synonyme de transfert d'État de représentation. C' est un style architectural qui guide les développeurs dans la création d'API. C' est donc un ensemble de règles qui aident les développeurs à créer des API. Maintenant. Et son niveau d'architecture d'arrestation le plus simple était une requête à envoyer sur Internet en utilisant des méthodes HTTP pour obtenir une réponse. Vous l'avez vu en utilisant divers exemples auparavant. Par exemple, si vous faites une demande à vous, l'application YouTube, vous l'avez faite via Internet et vous obtenez une réponse sous forme de vidéo. Maintenant, quels éléments constituent un message de demande ? Quels sont les différents types de méthodes HTTP, et à quoi ressemble une réponse ? Ce sont les choses que nous allons examiner dans les sections entrantes. 9. Éléments d'une API: Voyons maintenant ce qui constituait les éléments d'une API. Et il y a cinq éléments différents d'une API, qui est une méthode de réponse de requête, en-tête et un corps. Que signifient chacun de ces éléments ? On regarde un cours entrant. 10. Methods HTTP: Regardons maintenant les différentes méthodes HTTP. Ainsi, lorsque vous faites une demande ou Internet, vous utilisez des méthodes HTTP pour obtenir la réponse pertinente. Maintenant, regardons l'analogie du restaurant. Vous êtes allé au restaurant et la première chose que vous faites est de prendre le menu du serveur. Maintenant, l'acte d'obtenir est une méthode. De même, utilisez différentes méthodes pour obtenir la réponse appropriée du service Web. Ainsi, les méthodes HTTP courantes sont post, GET, PUT et delete. Maintenant, si vous êtes familier avec la base de données, vous seriez familier avec l'analogie de foule où c signifie créer nos quatre R3, vous pour la mise à jour, D pour la suppression. Maintenant de même, chacune de ces méthodes HTTP effectue ces fonctions. Par exemple, si vous utilisez la méthode GET, vous demandez des informations au serveur, si vous utilisez la méthode post, vous créez essentiellement une nouvelle entrée dans l'argent. Si vous utilisez la méthode put, vous mettez à jour ou créez une nouvelle ressource sur le serveur. Et si vous utilisez la méthode delete, en supprimant essentiellement une entrée du sud. Ce sont les différentes méthodes que vous pouvez utiliser via l'architecture d'API restante. Merci d'avoir écouté et j'espère vous voir la prochaine classe. 11. Demande et réponse à l'API: Maintenant, nous allons comprendre à propos de la demande. Maintenant, comme nous l'avons vu plus tôt, vous faites une demande en utilisant la méthode HTTP pour obtenir une réponse. Comment avez-vous envoyé une demande ? Vous avez envoyé une requête à une URL et vous envoyez également la méthode que vous souhaitez faire. Vous voulez obtenir, mettre un message ou supprimer n'envoie pas l'en-tête et les informations de corps dans le cadre de ce message. Et chaque fois que vous parlez d'URL, que faites-vous la classe d'URL ? Vous constituez déjà le protocole. Dans notre cas, c'est un protocole hétérotopique. Nous l'envoyons via Internet. Maintenant. Le second est le domaine, le site Web où les ressources sont hébergées. Et le troisième est le chemin. Et enfin, c'est le point de terminaison que nous voulons réellement atteindre qui vont être plusieurs points de terminaison différents qui retournent des réponses différentes. Donc, généralement une URL se compose de ces choses. Donc, la requête est faite à une URL avec une méthode spécifique, avec un corps et un en-tête. Maintenant, regardons une réponse. Disons que vous avez fait une demande, vous pouvez demander et vous allez obtenir une réponse de la requête API maintenant et une réponse à peu près la même, sauf qu'une réponse n'a pas d'URL ou de méthode. Au lieu de cela, il a l'en-tête des codes d'état , et le corps, lorsque vous faites une demande , ce que vous devez savoir est , a des demandes réussies, avez-vous obtenu ce que vous cherchez ou y a-t-il eu une erreur ? Ce sont donc des statuts indéfinis que vous obtiendrez dans la réponse à partir de laquelle vous pouvez savoir si votre demande a été réussie ou non. Et puis il aura un en-tête et un corps. Regardons cela dans les sections suivantes. 12. Données (Chargement de compte): Nous avons vu que ce corps fait partie de la demande et de la réponse. Que voulons-nous dire par corps ? Par corps, nous entendons essentiellement les données que vous envoyez à l'API et que vous obtenez également de l'API. C' est aussi appelé la charge utile. Donc, si vous êtes un développeur vous dit que à quoi ça plait ou ressemble ? Essentiellement, ils veulent que vous regardiez quelles sont les données que vous avez déjà envoyées ou reçues de l'API. Pourquoi avez-vous besoin d'envoyer des données via votre API ? Supposons que vous vous connectez à votre application Web. Le nom d'utilisateur et le mot de passe sont les données que vous envoyez afin l'application vous reconnaisse, vous authentifie et vous connecte à l'application. Par conséquent, les données sont généralement envoyées au format JSON ou XML. Maintenant, ce sont des façons de représenter votre charge utile. Alors, qu'est-ce que JSON veut dire ? Json signifie JavaScript Object Notation utilise essentiellement des objets pour définir les données qu'ils contiennent. Dans le quotidien est défini en utilisant des paires de valeurs clés comme celui-ci. Et il peut également représenter des tableaux en utilisant des crochets comme ceci. Vous pouvez également représenter des données sous la forme XML. Xml utilise des balises d'ouverture et de fermeture, puis des valeurs dans cela, et il utilise l'imbrication pour représenter des tableaux. Donc, ce sont deux formats populaires dans lesquels demande une réponse centrum que j'ai reçue de votre API. Je vais fournir des liens vers des ressources pour en savoir plus sur JSON et XML aux fins de ce cours pour être bon pour vous savoir que la demande et la réponse sont envoyées en utilisant le corps est également appelé la charge utile et le format dans lequel l'ascension, typiquement nos JSON et XML. 13. En-tête d'API: Bienvenue dans la dernière partie qui est les en-têtes. Mais lorsque vous envoyez votre demande à l'API, peut être API donner la réponse à elle demande. Donc, il ne devrait pas être un chèque si vous avez le droit de demander des informations. C' est donc ce qu'est l'authentification. Ainsi, vous pouvez envoyer quelques informations supplémentaires en utilisant l'en-tête du message. Nous allons donc discuter de deux informations importantes que vous envoyez. L' un est l'authentification, l'autre est Content-Type. Parlons d'abord de l'authentification. Il existe quelques schémas d'authentification différents qui sont disponibles sont les plus populaires sont l'authentification de base, qui utilise essentiellement votre nom d'utilisateur et de connexion pour s'authentifier. L' autre est la clé API, où vous envoyez une clé API unique avec votre demande. Et le troisième est pour l'instant de discuter du fonctionnement ces différents mécanismes d'authentification est au-delà du cadre de ce cours. Ces mécanismes d'authentification permettent au serveur de vérifier vos informations d'identification et de confirmer s'ils peuvent réellement répondre avec les données demandées ou non. Le suivant est le type de contenu. Donc, nous avons vu plus tôt que vous pouvez envoyer une charge utile dans différents formats, par exemple, JSON et XML lorsque le client envoie une demande, il peut également dire au serveur quel type de données vous pouvez accepter cela. Ainsi, nous pouvons également utiliser l'en-tête pour mentionner le type de contenu dans lequel les données sont. L' en-tête peut également être utilisé pour fournir des informations supplémentaires comme celle-ci. Donc, cela forme tous les éléments clés d'une API. Merci d'avoir écouté et j'espère vous voir la prochaine classe. 14. Leçon bonus - Webhooks: Salut tout le monde. Dans cette section bonus, regardons ce qui est un webhook. Ainsi, les webhooks se comportent légèrement différemment de ce que les API traditionnelles se comportent. Ils sont parfois appelés comme une API inverse. Et en tant que chef de produit, il est important que vous compreniez ce que sont les hameçons Web et où vous pourriez réellement les utiliser. Alors regardons cela en utilisant un scénario. Disons qu'un intégré avec PayPal. Chaque fois que quelqu'un vous fait un paiement sur papier, vous voulez que PayPal vous avertisse afin que vous puissiez expédier le produit. Maintenant, il y a deux façons de le faire. Un que vous pouvez continuer à vérifier PayPal, si un paiement a été reçu ou non. Paypal a des API. Vous pouvez vous abonner, vous pouvez cliquer sur cette API, obtenir la liste des réponses et voir s'il y a un nouveau paiement qui a été récupéré. Maintenant, vous pouvez le faire plusieurs fois et chaque fois que vous trouvez un nouveau paiement dans la réponse, vous pouvez alors déclencher votre propre processus interne afin d'expédier ce produit. Mais le processus de vérification de l'API, demandant une réponse à l'API plusieurs fois est un gaspillage de bande passante, ainsi que de votre système et de vos sources. Et pas seulement cela, de nombreux fournisseurs d'API vont avoir des limites sur le nombre de fois que vous pouvez réellement frapper l'API. Donc, chaque fois que vous allez frapper l'API, vous consommez vos limites. Donc, ce n'est pas un moyen idéal, serait en fait mieux si PayPal peut lui-même vous dire où un paiement a été reçu afin que vous puissiez alors vous assurer que la livraison des produits. Ici cependant, vous êtes le tiers qui dépend de PayPal. Paypal a tellement de consommateurs différents. Comment peuvent-ils alors notifier efficacement et le consommateur spécifique souvent événement. C' est là que leurs crochets entrent en image où les livres sont très utiles lorsqu'il y a un changement de statut ou un changement d'événement. Et une notification est attendue d' un fournisseur spécifique sur la base duquel vous souhaitez lancer votre propre processus. Donc, PayPal aurait une interface webhook où vous direz à quelle URL PayPal doit envoyer la notification d'événement spécifique afin que vous puissiez ensuite attendre jusqu'à ce que la notification ait été reçue, puis lancer votre propre processus. Donc, contrairement à une API où vous demandez et obtenez ensuite une réponse dans un hook Web, c'est un événement et ensuite basé sur quelle réponse est ensuite fournie. Donc, en général, ce sera un message de publication que PayPal ferait pour spécifier le point de terminaison HTTP. Et c'est ce que j'espère que c'était. Pour en savoir plus sur les crochets Web. J' ai joint quelques ressources dans les leçons. S' il vous plaît n'hésitez pas à les vérifier. 15. L'état d'esprit du produit API: Et ce verre, nous allons comprendre pourquoi il est important d'entrer dans l'esprit de regarder les API comme des produits et des types de projets. Maintenant, avant de le faire, commençons par regarder comment les API généralement un mur dans l'entreprise. Maintenant, prenez un exemple des hôtels Hilton. Ils ont un tas d'hôtels partout dans le monde. En règle générale, ce qui aurait pu se produire est qu'un client peut contacter et demander à l'employé de l'hôtel si, s'il peut réserver l'une des chambres pour une certaine période de temps. Donc, ce que la personne à la fin du comptoir pourrait faire, c'est obtenir une liste de toutes les chambres disponibles, donner ses informations de prix, faire une réservation, puis obtenir le paiement du client. Maintenant, comme la technologie aurait évolué, vous avez plusieurs canaux différents évoluant comme application Web pour les hôtels Hilton et par application. Maintenant, au lieu de répliquer le même processus pour chacun de ces systèmes différents, ce qu'ils auraient pu faire est une API de plate-forme a identifié quatre API et API différentes pour obtenir la liste de toutes les salles disponibles et API pour obtenir le informations de prix pour les chambres et l'API pour effectuer une réservation, puis obtenir le paiement de l'utilisateur. Ces quatre API auraient donc pu être consommées par ces différents canaux. Par conséquent, il y a un avantage à créer des API internes pour le groupe hôtelier Hilton. Et quelqu'un d'intelligent au sein de l'entreprise pourrait maintenant comprendre qu'il y a d'autres entreprises qui pourraient tirer parti des API pour Hilton Hotels , puis réserver des chambres pour Hilton via ces applications. Maintenant, des entreprises comme Expedia consomment ces API et permettent ensuite aux utilisateurs de réserver des hôtels via leur application. Il n'a donc pas plus de revenus grâce à une nouvelle opportunité d'affaires. Maintenant, je suis d'autres développeurs plus créatifs et ils pourraient éventuellement être à la recherche de permettre aux utilisateurs utiliser Amazon Echo ou Google aide sage pour faire une réservation d'hôtel en utilisant zippy. Il y a donc un nouveau canal et les opportunités d'affaires explorent de multiples possibilités. C' est donc l'avantage d' exposer les API à un marché plus large. Et c'est pourquoi, parce que les API, de sorte que tous les besoins spécifiques d'un ensemble spécifique d' utilisateurs finaux et fournissent également la possibilité de stimuler la croissance de l'entreprise. Ils devraient être examinés sur les produits et non sur les projets. Traditionnellement, la façon dont les API ont évolué, car elles sont conçues pour des audiences internes. La plupart du temps, ils sont considérés comme des projets. Vous savez, le besoin commercial, vos cas d'utilisation sont à peu près réglés. Vous commencez donc à créer les API avec un objectif final spécifique à l'esprit. Donc, vous regardez toujours les construire comme des projets. Vous ne pensez pas à 100 clients différents avec plusieurs cas d'utilisation. Cependant, c'est généralement ce qui va se produire une fois que vous exposez ces API à l'utilisateur final. Si vous ne le faites pas, cette mentalité de produit, ce qui pourrait arriver est que vous pourriez construire une API en tant que projet, puis vous exposer toutes les API aux développeurs tiers. Mais vous pourriez constater qu'aucun d'entre eux ne l'a réellement utilisé parce qu'ils n'en avaient vraiment pas besoin. Et donc tous vos efforts sont tombés dans le drain. Par conséquent, il est important de considérer les API comme des produits. Vous devez donc commencer à comprendre les utilisateurs. Quel genre de problèmes ces développeurs ont-ils ? Comment mon API pourrait-il les aider et ensuite venir avec un petit MVP d'une API, lancer sur le marché, validé, le tester et le nitrate et continuer à l'améliorer. Vous devez donc entrer dans l'esprit du produit pour vraiment réussir dans le lancement de votre produit API. 16. Cycle de vie API premier et API: Dans cette classe, comprenons ce que l'on entend par stratégie API première et examinons également un cycle de vie typique d'un produit API. Et qu'est-ce que l'API en premier ? Maintenant, nous avons tous convenu dans la classe précédente que vous devez sortir de l'état d'esprit du projet. J' arrive à l'état d'esprit du produit quand il s'agit de construire des API pour les utilisateurs tiers. Donc, si vous avez 20 API internes, vous ne pouvez pas simplement les exposer à l'utilisateur final. Ils peuvent donc rester inutilisés car les utilisateurs finaux peuvent ne pas avoir vraiment besoin de ces API. Donc, la première stratégie API signifie essentiellement que commencer par la conception et le contrat API avant d'implémenter réellement l'API. Et puis essayez de valider si cette API va réellement être utile à nos utilisateurs finaux. Ce que cela signifie, c'est que vous allez obtenir des commentaires anticipés. Vous allez identifier les lacunes dans vos processus métier ou vos détails techniques. Et vous serez en mesure de les corriger rapidement avant d'implémenter réellement l'API. Et parce que vous commencez par comprendre les utilisateurs et regarder comme une API pour l'utilisateur final d'abord, vous aurez le plus souvent une API qui sera effectivement utilisée et adoptée par un utilisateur final. Donc, avec cette compréhension, quoi ressemble le cycle de vie typique des produits API ? Alors commençons par le design. Ensuite, vous allez de l'avant et mettre en œuvre un MVP. Donc, vous allez construire l'informatique, la sécurité, tester, le libérer , le surveiller, puis j'échange dessus, et tout le processus se répète à nouveau. Donc, vous pouvez voir que cela ressemble à peu près à la façon dont un cycle de vie de produit traditionnel est également dans un monde agile. 17. Créer un produit viable minimum: Regardons maintenant l'importance de MVP en ce qui concerne les produits API, quand il s'agit de gérer les produits traditionnels, l'importance des MSP, bien compris. Je ne pense pas que les produits API et tout autre quand vous allez sur le marché la première fois avec une API est important de le regarder en termes de MVP, car il est important pour vous d'aller sur le marché rapidement avec une proposition de valeur que les développeurs aimerait adopter et ensuite apprendre de lui, et puis je l'échange le plus tôt possible. Par exemple, si votre L, vous pouvez avoir autant de backend de processus métier. Par exemple, vous pouvez avoir des API, API internes pour obtenir la liste de tous les restaurants dans un emplacement spécifique. Vous pouvez obtenir la liste de tous les restaurants qui sont cinq étoiles et au-dessus, obtenir la liste des restaurants avec les commentaires des utilisateurs dans un endroit spécifique et ainsi de suite. Mais est-il important d'exposer une API avec toute cette complexité ? Ou est-il important d'aller sur le marché avec une solution moins complexe, mais nous ne devrions pas vraiment être précieux. Par exemple, si vous allez exposer une API qui fournit une liste de restaurants par emplacement, est-il important de donner tous les différents paramètres de requête qui sont importants pour donner toutes les réponses dans la charge utile, peut-être pas. Il est donc important pour vous de regarder ce qui est un MVP afin que vous puissiez aller sur le marché plus rapidement et comment les développeurs l'adoptent, puis apprendre de lui et tester le nitrate dessus. Rappelez-vous que toutes ces expériences sont des expériences et toutes vos expériences ne vont pas réussir. Certains de vos MVP peuvent s'estomper. Mais rappelez-vous que MVP avec succès pourrait ouvrir des opportunités d'affaires entièrement nouvelles et la politique un aller sur le marché et obtenir des données, le mieux sera un argument pour donner justification commerciale pour des investissements supplémentaires, non ? Lecture sur cette partie. 18. Design, de produits API et développement: Et maintenant que nous avons examiné l'importance d'un MVP pour un produit API, regardons comment vous concevez réellement quelque chose et lancez un produit API. Les étapes impliquées sont légèrement différentes par rapport au produit traditionnel. Traditionnellement, que feriez vous s'il est possible que vous vouliez construire un prototype cliquable utilisant quelque chose comme dans la révision d' une application frontend, puis le montrer à certains de vos utilisateurs ou l'utiliser, examinez-le avant vous allez de l'avant et construisez l'application. Donc, quand il s'agit d'API, vous pourriez vouloir faire quelque chose de similaire à cela. Donc, le document de conception, le document de spécification API, est ce qui aide avec nous à concevoir l'API de première main, où vous pouvez dire quelles seront les spécifications de l'API, quelle sera la demande et la réponse ? Quel sera le point de terminaison que vous toucherez ? Quels sont les différents paramètres de requête que vous allez prendre en charge et ainsi de suite. Maintenant, avec le document de conception prêt, vous pouvez ensuite le faire examiner pour vous assurer qu'il fournira des Databricks uniformes empêche qu'il ne fait une API conforme à nos API précédentes est des conventions de nommage impaires, le versionnage , tout ce qui est conforme à nos normes. Utilisez-vous des jargons ? Quel genre de dénomination faisons-nous réellement ? Utilisons-nous des structures imbriquées pour une extensibilité future ? Je vais utiliser des énumérations, deux Booléens pour de nouvelles propriétés. Par exemple, si la réponse a une colonne d'état qui dit oui ou non comme un état binaire est, vous préférez être le succès ou l'échec si nécessaire à l'avenir à un état intermédiaire appelle grenouille en cours, ainsi de suite et ainsi de suite. Donc, le processus de révision va être très utile pour itérer réellement sur l'API conçue pour l'obtenir largement avant qu'elle ne soit réellement implémentée. Et une fois que vous avez fait cela, l'étape suivante serait de faire des tests utilisateur, où vous utiliserez ceci pour tester avec un ensemble de groupes sélectionnés pour vérifier si l'API va réellement être utilisable. Vous pouvez également créer une API et exposer la première version pour une utilisation expérimentale. Une façon typique d'utiliser cela serait la fooding pour chien. Vous voudrez peut-être le relâcher à vos utilisateurs internes. Par exemple, votre personnel d'abord, demandez à tous vos employés de commencer à utiliser l'API et de fournir des commentaires. Et nous avons également mis en place des entretiens avec d'autres développeurs tiers avec lesquels vous avez des relations commerciales. Les développeurs tiers pour vraiment comprendre l'API manque quelque chose. Une fois que vous avez eu tous ces éléments et que j'ai itéré construire l'API, vous pourriez continuer avec une version préliminaire bêta publiée pour tous les utilisateurs. Ou vous pouvez faire une libération fermée où vous placez l'API derrière une porte et autoriser l'accès à un ensemble spécifique d' utilisateurs pour comprendre comment ils l'utilisent réellement. Si vous voulez vraiment apporter d'autres modifications avant d'opter pour une version de disponibilité générale. C' est donc à peu près le cycle de vie. Et c'est quelque chose que vous devez garder à l'esprit. Chaque fois que nous commençons à construire une nouvelle API. 19. Développer l'adoption grâce à l'expérience de développeur intuitive: Une fois que vous avez un MVP disponible, la prochaine étape du cycle de vie du produit API consiste à stimuler l'adoption, la mesure. C' est l'usage, et puis j'échange dessus. Et comment conduisez-vous l'adoption ? C' est la première étape clé pour stimuler l'adoption est d'avoir un excellent portail de développeurs. Parce que votre utilisateur final pour l'API est au moins votre développeur tiers. Il est donc important pour eux de pouvoir tout comprendre sur l'API facilement en regardant la documentation. Vous devez donc disposer d'une excellente documentation, d' excellents guides d'utilisation, d'un environnement sandbox pour les tester. Exemple, cas d'utilisation, peut-être forums. Il y a tellement de façons différentes que vous devez y penser que vous pouvez rendre la vie de votre développeur facile. Donc, les développeurs ne vont généralement pas passer beaucoup de temps dans votre portail de développeurs initialement quand il recherche sur l'API. Cela signifie être très simple, facile et intuitif à comprendre afin qu'ils puissent se lever et fonctionner le plus rapidement possible, peut-être même 30 minutes. Il est donc important d'investir beaucoup de temps pour rendre l'expérience des développeurs géniale. Donc, vous avez besoin d'un grand portail de développeurs Merci à vous jeunes de l'année prochaine et besoin de se concentrer sur l'évangélisation de votre API. Qu' est-ce que je veux dire par là ? Si vous pensez que vous allez simplement construire une API, mettez-la là, et les gens vont juste entrer et l'adopter. Ça n'arrivera pas. Vous devez envoyer la proposition de valeur outil approprié les tableaux de bord afin que DID puisse, ils seraient vraiment intéressés par l'utilisation de l'API. Ça n'a pas d'importance. L'API dispose d'une API interne ou d'une API externe. Même si vos développeurs, même s'il y a des utilisateurs internes pour l'API que vous construisez au sein l'organisation, est important de vendre la proposition de valeur, n'est-ce pas ? Pour qu'ils puissent l'adopter. Alors participez à des conférences, organisez des webinaires, sortez le message pour vendre la proposition de valeur de la bonne façon à vos utilisateurs. Et une fois que vous avez assez d'adoption, mesurez, comment les gens l'utilisent. Sommes-nous réellement en mesure de répondre aux besoins de l'utilisateur ? C' est assez sûr ? Donc, en essayant de comprendre et de fournir pour mesurer les métriques. Alors, comment mesurez-vous les métriques et comment savez-vous quoi mesurer ? Vous devez donc définir les indicateurs de performance clés. Et c'est ce que nous allons examiner dans la section suivante. 20. Les métriques: La prochaine étape de la gestion efficace des produits VM consiste donc à mesurer les métriques qui comptent vraiment. Donc, pour ce faire, vous devez identifier les indicateurs de performance clés de l'API. Donc, d'abord, pensez à quel est le but de votre API vraiment ? Il s'agit de votre API destinée à générer des revenus directs pour votre entreprise. Par exemple, les utilisateurs effectuent des achats via l'API afin que vous attendiez à ce que votre chiffre d'affaires mensuel augmente réellement, ou est-ce qu'il s'agit de générer des revenus directs ? Lorsque, en exposant une API qui fournit les commentaires d'un restaurant spécifique, vous attendez plus de visites de clients sur la page du restaurant sur votre site Web, et donc plus de réservations au restaurant à partir de votre site Web, et donc le augmentation des revenus. Donc, ici, la métrique pourrait être un certain nombre de nouveaux utilisateurs enregistrés via l'API ou le nombre d'utilisation de restaurant via l'API et ainsi de suite. Quel est le but de votre API pour générer de nouvelles opportunités commerciales ? Ou s'agit-il d'augmenter votre taille d'utilisateurs de développeurs ou d'augmenter la taille de votre écosystème de partenaires. Il est donc important que vous compreniez vraiment quel est votre moteur commercial clé pour cette API et donc, puis déterminez la métrique appropriée non Star. Et l'autre pourrait être de suivre également l'utilisation de l'API. Par exemple, nos développeurs utilisent l'API comme il est prévu, combien de fois ils appellent l'API, quels paramètres de requête utilisent-ils le plus ? Et obtenent-ils la réponse qu'ils recherchent le plus souvent ? Et suivez également l'expérience des développeurs à travers le portail. Ils obtiendront s'enregistrer et obtenir la clé API rapidement. Sont-ils capables de se lever et de fonctionner plus rapidement ? Donc, le suivi de toutes ces mesures va vous donner les commentaires dont vous avez vraiment besoin pour en faire une, identifier les API qui ont vraiment atteint une métrique métier et donc se concentrer sur l'itération et l'amélioration de l'API pour également regarder le développeur expérience. Comment rendre l'expérience du développeur plus agréable ? Quelle partie du voyage définit le plus de friction ? Et puis cela vous aidera aussi avec vos stratégies de monétisation. Il est donc important d'obtenir des commentaires anticipés afin que vous puissiez suivre ces mesures pour une nouvelle API, cela va être important. Il va être difficile d'obtenir la rétroaction dont ils ont besoin. Vous devez donc utiliser vos connexions pour obtenir ces premiers développeurs à bord. C' est donc là que l'évangélisation de l'API entre vraiment en image. Organiser des conférences sur les hackathons, tendre la main à vos partenaires et ainsi suite sont des moyens de faire démarrer l'adoption de l'API. 21. Versioning API: Salut tout le monde. Regardons maintenant la gestion des versions de l'API. Maintenant, quand il s'agit de Versioning, c'est assez simple pour les produits traditionnels. Et souvent, chaque fois que vous publiez une nouvelle version aux utilisateurs finaux, ils peuvent même ne pas remarquer que l'aversion a été faite parce que les versions sont souvent petites et fréquentes. Donc, l'un des principes clés de Vijay pour faire des versions fréquentes et petites afin que vous puissiez apprendre des utilisateurs. Apis serait très difficile pour vous de faire des versions plus récentes des API. C' est parce que pensez à la façon dont les API fonctionnent. Vous publiez une API à un tiers et un ou plusieurs tiers se seraient intégrés à l'API si vous créez une nouvelle version de l'API, ce qui signifie que tous les utilisateurs tiers existants devraient faire du code change afin qu'ils puissent maintenant pointer vers la nouvelle version de l'API. Donc, processus de réflexion donc prudent devrait être payé. Avant de publier une nouvelle version d'une API. Vous pouvez choisir des améliorations à une API existante tant qu'aucune d'entre elles ne rompt les modifications. Alors, quand devriez-vous envisager une nouvelle version ? Donc, ce serait quand il y a un changement de rupture à vos consommateurs de l'API en raison des améliorations apportées à l'API. Qu' est-ce que je veux dire par briser les changements ? Vous envoyez donc quelques détails dans votre réponse API. Maintenant, vous allez trouver que la charge utile est trop gonflée et vous pensez que vous devez peut-être supprimer certaines des réponses. Si vous supprimez cela, il pourrait y avoir beaucoup de QBI, beaucoup de développeurs tiers qui pourraient s'attendre à la réponse très disponible dans l'API. Si vous le supprimez, alors le processus osez pourrait effectivement être affecté. Ou disons que vous avez changé l'URI. Donc tous ces changements cassent. Et si vous deviez les faire, vous devez publier une nouvelle version de l'API. Avant de faire une nouvelle version de l'API, vous devez également penser, combien de temps allez-vous prendre en charge la version précédente de l'API. Parce que chaque version aura des coûts de maintenance associés à elle. Donc, vous devez donc, vous devez ensuite regarder les données pour voir combien de consommateurs utilisent la version précédente de l'API et sont-ils prêts à passer à la nouvelle API ? Vous devez donc fournir une chronologie suffisante pendant combien de temps vous prendrez en charge cette version précédente sur l'APA afin qu'ils aient suffisamment d'informations à l'avance pour choisir de migrer vers la nouvelle version ou non. Par conséquent, compte tenu de l'importance du versioning et de l'API, il est également important de communiquer directement et clairement à tous vos consommateurs. Chaque fois que vous raisonnez que vous lavez, vous devez utiliser votre portail de développeurs et tous les autres canaux qui sont à votre disposition, pour les développeurs tiers. Donc, à ils sont tous suffisamment conscients, l'autre chose importante à laquelle vous devez penser est comment nommez-vous la version ? Maintenant, il existe différentes normes que les différents développeurs d'API suivent. Certains d'entre eux aimeraient avoir le numéro de version dans le cadre de l'URI, disons que c'est la version 2 ou la version 20. Certains d'entre eux aimeraient avoir une date dans le cadre de l'URI. Certains d'entre eux souhaitent fournir les informations de version dans le cadre de l'en-tête. n'y a donc pas une seule façon ou une bonne façon de le faire. Mais la façon la plus courante, le moyen le plus simple serait de fournir le numéro de version réel dans le cadre de l'URI. Donc, quel que soit le format, quelle que soit la norme que vous suivez réellement, vous devez avoir la cohérence entre toutes les API de toutes les API que vous gérez réellement. Parce que les développeurs vont s'habituer à une certaine façon. Et si vous suivez, en fournissant différents types d'avertissement et ils ne sauraient pas comment rechercher la dernière version et comment les consommer. 22. Pitts d'une API mal conçue: Regardons maintenant les pièges d'une API mal conçue et développée. De nombreuses entreprises lancent des API sans vraiment comprendre les besoins des utilisateurs des besoins des développeurs sur le marché, ce qui conduit à une API mal conçue qui est soit moins adoptée ou il n'y a pas d'adoption grande. Donc, une grande partie des efforts et des coûts qui ont été dépensés dans la conception de l'API, exposer l'API descend le drain. La façon de le corriger sera pour les développeurs de commencer à concevoir et à développer une nouvelle API et de la refiler à un système back-end et de lancer une nouvelle version de l'API, ce qui est un exercice coûteux. Ce qui ferait pire, c'est que si vous aviez une certaine adoption pour la version antérieure de l'API, cela pourrait signifier que vous pourriez avoir à déplacer certains de ces utilisateurs vers la nouvelle version de l'API, ou vous pourriez décider de prendre en charge la précédente de l'API, qui vont tous ajouter à votre douleur et vos coûts. Maintenant, un autre piège commun est d'exposer une API avec un système back-end mal conçu. système back-end pourrait avoir des processus métier d'architecture hérités qui ont évolué au fil du temps et qui n'ont pas été optimisés pour des gains d'efficacité. Donc, si vous allez exposer une API qui sera moins facilement compréhensible, adoptable et évolutive. Et puis cela va conduire à une très mauvaise adoption. Donc, la seule façon de résoudre ce problème est de commencer par comprendre les besoins de l'utilisateur , puis de concevoir une API bien définie à l'avance. 23. La valeur d'une API bien pensée: Quelles sont les valeurs de l'API bien définie ? Maintenant, API est si vous allez sur le marché avec une API bien définie et qui est grandement adopté, il conduira à de nouvelles opportunités d'affaires pour votre entreprise maintenant créé un développeurs tiers pourraient utiliser vos API d'une manière que vous n'avez jamais imaginé était possible. Par exemple, lorsque l'API Maps a été exposée, ils n'auraient pas vraiment pensé à un cas d'utilisation d' une application de livraison de restaurant utilisant cartes pour réellement montrer quand la livraison se déroule correctement ? Maintenant. C' est une nouvelle opportunité d'affaires pour les développeurs de cartes et cela crée des revenus accrus. Et une autre chose est une API bien définie et facilement compréhensible va avoir des effets de mise en réseau. D' autres développeurs tiers vont examiner l'adoption réussie d'un cas d'utilisation, puis entrer, créer plusieurs autres cas d'utilisation. Donc, vous allez avoir une augmentation de chiffre d'affaires, de nouvelles opportunités d'affaires se développer, et votre entreprise va croître beaucoup plus. 24. Qui forment l'équipe API: Salut tout le monde. Dans cette section, examinons l'importance de l'équipe API et qui forme l'équipe API. Ainsi, l'équipe API se compose généralement du gestionnaire de produit API, l'architecte API, des développeurs API et de l'évangéliste APA. Désormais, dans de nombreuses organisations, ils ne sont peut-être pas une équipe d'API dédiée, mais de plus en plus, les organisations comprennent l'importance d'avoir une équipe d'API dédiée, avoir la mentalité des produits et de créer des API en tant que produits. Les responsables de produits APA sont donc des éléments clés de cette équipe. Dans les quelques conférences suivantes, vous avez appris que vous comprenez spécifiquement les rôles et les responsabilités d'un gestionnaire de produit API, des architectes, des développeurs et de l'APA sans valeur. Merci d'avoir écouté et j'espère vous voir dans la prochaine classe. 25. Introduction à des stratégies de facturation des API: Passons maintenant à une partie très importante de la gestion des produits API, qui est les stratégies de tarification des APA. Comment monétisez-vous votre API ? Tout d'abord, qu'est-ce que la monétisation ? Pour le dire simplement, il s'agit de gagner de l'argent via votre API. Et la façon dont tu gagnes de l'argent, ça pourrait être très différent. Il se peut que chaque fois que quelqu'un doit utiliser votre API, il ait besoin de vous payer et donc vous gagnez de l'argent. Donc, c'est un revenu dyadique. Ou il se peut que chaque fois qu'ils utilisent une API et effectuent un achat de votre produit ou service, vous gagnez réellement de l'argent. Il pourrait donc y avoir des répercussions directes sur les revenus pour l'API. C' est un modèle d'affaires. L' autre pourrait être, vous pourriez offrir une API gratuitement parce qu'elle va indirectement profiter à votre entreprise. Par exemple, Google et Facebook peuvent proposer l' utilisation de leurs API parce qu'ils obtiennent plus de données client, ce qui ne va pas directement les aider à fournir des services plus personnalisés à leurs clients. De même, il pourrait s'agir de plusieurs autres façons indirectes dont l' utilisation de l'API pourrait affecter votre entreprise. Donc, c'est essentiellement ce que dit la monétisation. Dans les prochaines sections, nous allons discuter de quelques-unes des stratégies de tarification populaires pour les API. 26. Options de facturation API: En ce qui concerne les stratégies de monétisation pour les API sont essentiellement quatre. Il existe donc généralement quatre façons différentes pour les entreprises de tarification des API. L' un est gratuit, il n'y a pas de prix pour l'utilisation dans le travail de l'API. Le suivant est le développeur paie pour l'API. Le troisième est que le développeur est payé pour l'utilisation de l'API. Et le dernier est les opportunités d'affaires indirectes. 27. Parties à l'économie API: Donc, avant d'examiner les stratégies de tarification spécifiques pour une API, nous allons d'abord comprendre qui sont les parties prenantes dans l'économie de l'API. Donc, d'abord, c'est le fournisseur d'API. Essentiellement, c'est l'entreprise a décidé d' exposer un tas d'API à des utilisateurs tiers, et l'intervenant détermine réellement le prix. Et ensuite, les développeurs d'API qui consomment réellement cette API et en construisent quelque chose et l'offrent à leurs utilisateurs finaux. Donc, enfin, ce sont en fait les utilisateurs finaux qui ont bénéficié de l'API. Ils ne voient pas nécessairement l'API, mais sont vraiment les bénéficiaires réels de la fonctionnalité offerte par l'API. Pour que votre stratégie de monétisation soit vraiment couronnée de succès, il est important que l'API soit bénéfique pour les trois parties prenantes. Donc, quel est le prix que vous avez déterminé pour l'API ne devrait pas seulement être bénéfique pour votre entreprise, mais il devrait également être durable pour le développeur de l'API afin qu'il soit en mesure de fournir une valeur à ces utilisateurs finaux. Donc, si vous dites que votre API va coûter X montant, mais la valeur réelle que les développeurs tiers obtiennent réellement est inférieure à X montant qui vous paie réellement. Ce n'est pas aussi une stratégie de monétisation durable. Gardez donc à l'esprit ces trois parties prenantes différentes lorsque vous pensez aux différentes options de tarification en face de vous pour votre API. 28. Tarification API: Maintenant, regardons la première option qui est gratuite. Pourquoi une entreprise offrirait-elle une API gratuitement ? Donc, vous proposeriez une API gratuitement pour diverses raisons. L' un pourrait être que vous vouliez augmenter l'adoption. Donc, près de devenir nouveau sur le marché, il n'y aurait personne qui pourrait voir la valeur de l'API assez. Donc, vous voudrez peut-être prouver le cas d'utilisation de l'API et donc vous proposez initialement une arborescence, ou vous pourriez vouloir conserver les consommateurs qui est une concurrence accrue. Donc, vous voulez offrir des services API de sorte que plus en plus de partenaires qui font réellement un partenariat avec vous plutôt que de la concurrence. Ou il se peut que vous obteniez quelque chose d'avantage dag. Par exemple, les connexions sociales qui sont disponibles, comme go, vous pouvez vous connecter via Facebook, inscrire via Google et ainsi de suite. Ces API sont souvent offertes gratuitement. Mais l'avantage que ces entreprises obtiennent, c'est plus de données sur l'utilisation des clients. Ce que cela profite aux développeurs tiers, c'est parce qu'il offre un moyen très facile d'identifier l'utilisateur et de simplifier le processus de connexion. C' est donc un gagnant-gagnant pour les trois parties au sein de l'économie API. Il existe donc des cas d'utilisation légitimes pour lesquels vous pourriez envisager d'offrir votre API gratuitement. 29. Développer le prix API: Le modèle de monétisation suivant est l'endroit où le développeur paie réellement pour l'utilisation de l'API. Pour que ce modèle réussisse juste dévaluer que le développeur obtient par l' utilisation de l'API devrait en fait être plus que ce que l'APA est réellement prix. n'est qu'alors que les développeurs qui envisagent réellement de payer pour l'API. Il y a encore une fois, différentes façons dont vous pouvez prix et API. Par exemple, il pourrait s'agir d'un modèle de paiement à l'utilisation, d'un modèle de freemium, d'un modèle à plusieurs niveaux ou d'un modèle basé sur les frais de transaction. Donc, lorsque vous dites que le modèle de paiement à est développé ne paie que lorsqu'ils utilisent réellement l'API. Donc, chaque fois qu'ils utilisent API qui collent réellement dans le montage, un bon exemple pour cela peut être une application de vérification de crédit. Donc, lorsque vous demandez un prêt pour la banque, banque fait un appel à l'agence de vérification du crédit et elle paie un certain montant pour cette vérification de crédit spécifique. L' autre pourrait être un modèle d'affaires freemium où vous offrez soudainement une faible valeur API fonctionnalités gratuitement. Alors que s'ils veulent des fonctionnalités premium réelles sont différents points de terminaison qui sont de plus grande valeur. Ils devront réellement payer pour cette API. Ceci est similaire à la façon dont les applications traditionnelles offrent des modèles Freemium. C' est pour amener les gens à adopter leur API spécifique sur habitué à elle et comme, et ils optent pour une version payante. Le troisième est un modèle hiérarchisé où, où vous pourriez le définir ici en disant que chaque pour 10 mille coups par jour, vous pouvez réellement payer autant. Si vous l'utilisez entre dix mille, quinze mille coups par jour, vous aurez en fait payé autant. Ou si vous dépassez les niveaux auxquels vous avez souscrit, vous devrez payer un montant vraiment élevé. Donc, donc vous pouvez déchirer le prix d'une manière. Et les développeurs pourraient réellement choisir et choisir l'affaire qu'ils pensent être ce que leurs frais d'utilisation réels. Maintenant, le dernier est un modèle basé sur les frais de transaction. Où obtiendrez-vous une commission pour la transaction ? Paypal ou Stripe ou l'une des applications de paiement. Un bon exemple. Ainsi, chaque fois que vous appuyez sur une API de paiement et effectuez une transaction et vous obtenez un certain pourcentage de frais pour la transaction. Donc, ce sont les différents modèles dans lesquels vous pouvez tarifier l'API. Et ce ne sont pas les seuls moyens que vous pouvez réellement les prix, mais ce sont quelques-unes des façons populaires. 30. Le développeur de prix API est payé: Le modèle de monétisation suivant est l'endroit où le développeur est payé pour l'utilisation de l'API. Donc, ce modèle peut être utilisé où vous, en tant que fournisseur d'API, êtes en fait le plus profité par l'API est utilisée par un développeur tiers. Donc, vous devez inciter les développeurs à utiliser l' API et donc vous payez l'API. Donc, quelques exemples pour cela est de voyages agrégateurs de vols ou agrégateurs d'hôtels sont effectivement bénéficier de ce modèle de tarification. Par exemple, chaque fois qu'une vente est effectuée via l'API spécifique IS, un hôtel les exploite et fournit effectivement une commission. Les développeurs parce qu'ils agissent essentiellement en tant qu'agents conduisant plus de ventes à mon hôtel. Donc, un autre modèle populaire est le modèle de référence ou d'affiliation. Vous savez peut-être qu'il peut s'agir d'un utilisateur affilié Amazon peut conduire des achats de produits sur Amazon, vous recevez des frais pour chaque référence. De même, s'il y a plus de trafic ou plus d'achats effectués sur votre site Web via des sites Web affiliés, vous pouvez encourager les développeurs en les payant. Certains des exemples populaires sont, vous savez, Google et Google AdWords, compagnies d'assurance et agents, ou dans un site d'emploi comme Monster.com et ainsi de suite.