[Shenzhen] Yuanchuanghui : 17h26, la salle des fêtes vous attend.

De nombreux amis étaient déjà très compétents dans le domaine qu'ils exerçaient lorsqu'ils sont devenus chefs de produit, mais ils entendaient toujours inévitablement des plaintes de développeurs : « Pourquoi y a-t-il tant de demandes alignées et tant d'interfaces qui ne peuvent pas être réalisées ? le manager a seulement dit Pouvez-vous exprimer avec un regard confus : Interface ? Ce que c'est? N'ai-je pas déjà écrit en détail les fonctions de ma page dans le document ?

En fait, au niveau du système, en plus du contenu visible tel que la rédaction et les boutons, il existe également de nombreuses chaînes logiques cachées sous le contenu - des interfaces, que nous appelons souvent API . Cet article vous aidera à mieux comprendre et utiliser les API en vous basant sur les connaissances de base des API et les scénarios commerciaux spécifiques des chefs de produit, afin que vous puissiez coopérer plus efficacement avec les développeurs.

Qu’est-ce que l’API ?

L'API, ou Application Program Interface, est un ensemble de règles définies qui permettent à différentes applications de communiquer entre elles. Il agit comme une couche intermédiaire qui gère le transfert de données entre les systèmes, permettant aux entreprises d'ouvrir leurs données et fonctionnalités d'application à des développeurs tiers externes, à des partenaires commerciaux et à des services internes de l'entreprise.

Source de l'image : CSDN@tbprice

Le fonctionnement de l’API est en fait facile à comprendre. Nous pouvons facilement comprendre le fonctionnement de l'API en l'expliquant via le paiement WeChat. Lorsque nous commandons des plats à emporter, le système nous invite à « utiliser le paiement WeChat » ou d'autres types de méthodes de paiement tierces. Cette fonction de paiement s'appuie sur l'API pour être complétée. Lorsque l’on clique sur le bouton de paiement, un appel API est effectué pour récupérer les informations (également appelé requête). La requête est gérée depuis l'application vers le serveur Web via l'URI (Uniform Resource Identifier) de l'API, qui comprend le verbe de requête, les en-têtes et parfois le corps de la requête.

Après avoir reçu une demande valide de la page Web du produit, l'API appelle un programme externe ou un serveur Web, c'est-à-dire un système de paiement tiers. Le serveur envoie une réponse à l'API contenant les informations demandées. L'API transfère les données à l'application demandeuse initiale, en l'occurrence le site Web du produit. Bien que le transfert de données varie en fonction du service Web utilisé, les demandes et les réponses s'effectuent toutes via l'API. Ces transferts ne sont pas visibles par l'interface utilisateur, ce qui signifie que l'API échange des données au sein de l'ordinateur ou de l'application et apparaît à l'utilisateur comme une connexion fluide et transparente.

Comment les API sont-elles classées ?

À mesure que les scénarios de communication évoluent, les dimensions de classification des API seront également différentes :

Répartis selon les fournisseurs d'API : API propre, API tierce (par exemple : authentification d'identité , service SMS , service de paiement , IA grand modèle , etc.).
Répartis selon les attributs techniques de l'API : API système (par exemple : mise en cache, timing, notification, surveillance, etc.), API métier (API d'adhésion, API produit, API de contenu, API de transaction, etc.), API de plateforme (API de connexion individuelle , API de recherche, service client IA), API, etc.).
Réparti selon les méthodes d'appel de l'API : API synchrone, API asynchrone.
Divisé selon la granularité de l'API : API de service (par exemple : API Meituan Takeaway , API Taobao Mall, API JD Express, etc.), API fonctionnelles (par exemple : API de chaîne courte , API de localisation , API d'authentification d'entreprise , etc.).
Répartis selon que l'API est ouverte sur le monde extérieur : API interne, API ouverte.

Dans quels scénarios les chefs de produit doivent-ils concevoir des API ?

Lors du développement d'applications basées sur Internet (applications SPA, applications APP, petits programmes, applications pour appareils intelligents, etc.), l'architecture technique est essentiellement un modèle client-serveur. À l'heure actuelle, le serveur est essentiellement une API et le chef de produit. il suffit de décrire l'entreprise.
Lorsqu'ils fournissent des interfaces techniques aux utilisateurs en amont et en aval, elles sont essentiellement fournies sous forme d'API. À l'heure actuelle, les chefs de produit doivent concevoir et définir des API.
Lorsque les services d'entreprise sont monétisés et fournis sous forme d'API, les chefs de produit doivent concevoir des API, définir des API, fixer le prix des API, etc.

Dans quels scénarios les chefs de produit utiliseront-ils des API tierces ?

En raison de facteurs de coût, de facteurs de détention de données ou de ressources, de facteurs de capacité technique, etc., lorsque les entreprises développent des systèmes numériques, il est impossible de développer tous les services par elles-mêmes, ni de les construire en utilisant largement du code source tiers. Les API multi-parties sont devenues un choix incontournable.

Scénarios de base courants, tels que la connexion : lors de la conception d'une application, la fonction la plus élémentaire est la fonction de connexion de l'utilisateur. Les utilisateurs n'ont pas besoin d'enregistrer des comptes séparés dans chaque logiciel, mais peuvent utiliser WeChat, QQ, Alipay et d'autres comptes pour se connecter. le programme de candidature. Des scénarios similaires incluent l'authentification KYC , l'authentification unique, la gestion de la sécurité, la collecte et le paiement de fonds, le partage social, la communication avec les utilisateurs, etc.

Scénarios utilisant les ressources de la plateforme, telles que les réservations de voyages : La fonction de base des principaux logiciels de plateforme de voyage est de regrouper les informations sur les vols et les hôtels et d'afficher différents prix à différentes dates. Habituellement, ces données proviennent de milliers de sites Web et de pages d'accueil, et ce service est également complété via une API. Des scénarios similaires incluent la livraison express et la logistique , les plateformes de plats à emporter, plusieurs grandes plateformes de commerce électronique, etc. Les entreprises doivent utiliser des API tierces.

Scénarios utilisant des capacités techniques tierces, comme les grands modèles d'IA : les grands modèles d'IA sont un nouveau favori en 24 ans. La plupart des entreprises ne peuvent pas les développer elles-mêmes et les utiliseront principalement. Des scénarios similaires incluent également la technologie du cloud computing, la technologie blockchain , la technologie du big data, la technologie de stockage, etc.

Utilisez des applications SaaS d'entreprise telles que CRM : les plates-formes telles que CRM (outils de gestion de la relation client) incluent souvent de nombreuses API intégrées qui permettent aux entreprises de s'intégrer aux applications qu'elles utilisent déjà, telles que les applications de messagerie, de médias sociaux et de messagerie. Cela réduit considérablement le temps passé à basculer entre différentes applications pour effectuer des tâches de vente et de marketing. Des scénarios similaires incluent le SaaS financier, le SaaS humain, le SaaS de bureau, le SaaS marketing, etc.

Comment un chef de produit rédige-t-il une bonne documentation produit API ?

Les principaux lecteurs du produit PRD sont le développement back-end (RD), le développement front-end (FE), les concepteurs d'interactions (UI, UE) et les tests (QA). Ils obtiendront les objectifs de travail dont ils ont besoin pour atteindre le PRD. , et utilisez-les pour concevoir le plan de base.

Dans l'article précédent, nous avons acquis des connaissances sur les API et disposions d'un langage pour communiquer avec les développeurs. Nous devons maintenant transformer ces connaissances en une description de nos besoins afin que les développeurs puissent comprendre nos besoins.

Voici un cas spécifique : supposons que nous soyons le chef de produit d'une plateforme de commerce électronique et que nous devions maintenant concevoir une nouvelle API pour implémenter la fonction de création de commandes d'utilisateurs. Lors de la rédaction de la documentation du produit API, nous devons prendre en compte les aspects suivants.

Description de la fonction de l'interface : Tout d'abord, nous devons clarifier quelle est la fonction de cette API, c'est-à-dire la création de commandes utilisateur. Décrivez la fonction en détail dans le document, y compris les paramètres d'entrée, les résultats de sortie, etc.
Description des paramètres : Pour la fonction de création de commande, des paramètres tels que les informations utilisateur, les informations produit, les informations de paiement, etc. peuvent être impliqués. Répertoriez tous les paramètres possibles dans le document et expliquez la signification, le type et si chaque paramètre est obligatoire.
Exemples de requêtes : fournissez plusieurs exemples de requêtes spécifiques pour montrer comment les développeurs appellent l'API pour implémenter la fonction de création de commande. Les exemples doivent couvrir les combinaisons de paramètres dans différentes situations pour garantir une compréhension claire par les développeurs.
Résultat de retour : décrit le type de résultat de retour qui sera obtenu après l'appel de l'API, y compris le succès et l'échec. En cas de succès, les informations sur la commande retournée doivent être décrites en détail ; en cas d'échec, la raison de l'échec doit être expliquée.
Définition des codes d'erreur : définissez les codes d'erreur possibles et leur signification afin que les développeurs puissent localiser rapidement les problèmes en fonction des codes d'erreur lors de l'appel des API.
Considérations de sécurité : pour les API qui impliquent des informations sensibles telles que la confidentialité des utilisateurs ou le paiement, la sécurité doit être prise en compte. Expliquez dans le document comment assurer la sécurité des informations utilisateur, comme l'utilisation du protocole HTTPS, le cryptage des paramètres, etc.

Grâce à la description détaillée ci-dessus, les chefs de produit peuvent rédiger une documentation produit API claire et complète, communiquer efficacement les exigences aux développeurs et s'assurer qu'ils peuvent correctement implémenter les fonctions requises.

Comment communiquer avec l'équipe de développement à propos de l'API ?

Normes uniformes

La communication est indispensable au projet. Avant de se connecter avec des partenaires de développement, les chefs de produit doivent prêter attention à l'unification des normes et des méthodes pour une meilleure modification et un meilleur suivi.

plateforme unifiée

À l'aide de plates-formes modernes telles que la plate-forme iPaaS et la passerelle API, les entreprises établissent d'abord la cohérence de la mise en œuvre au niveau technique sous-jacent, exploitent les capacités de la plate-forme, ignorent la complexité technique et se concentrent sur l'entreprise elle-même.

outil unifié

Lorsque le personnel technique effectue la conception d'API, il peut utiliser des outils de conception d'API pour permettre aux chefs de produit, aux développeurs et aux testeurs de communiquer, de programmer, de mettre à niveau et de maintenir une vue commune.

Connaissances techniques essentielles des API pour les chefs de produit