Vous consultez la documentation Apigee Edge.
Consulter la documentation d'Apigee X en savoir plus
Plusieurs concepts sont des idées courantes ayant une signification particulière dans Apigee.
| Terme | Définition |
|---|---|
| API | Proxy faisant office de façade pour votre API existante. Au lieu d'appeler votre API existante, les développeurs commencent à appeler la nouvelle API générée par Apigee. Cette façade dissocie l'interface publique de votre API backend, ce qui empêche les développeurs d'apporter des modifications au backend, tout en vous permettant d'innover en périphérie sans affecter vos équipes de développement internes. Lorsque vous apportez des modifications au backend, les développeurs continuent à appeler la même API sans interruption. Dans les scénarios plus avancés, Apigee vous permet d'exposer plusieurs interfaces à la même API. Vous pouvez ainsi personnaliser la signature d'une API pour répondre simultanément aux besoins de plusieurs groupes de développeurs. |
| chemin de base et ressources d'API | Une API est composée d'un chemin de base et d'un ensemble de ressources (également appelées chemins d'accès aux ressources). Pour chaque API, vous définissez une URL racine unique et plusieurs chemins d'accès aux ressources. Une API est semblable à un ensemble d'URI qui partagent tous un chemin de base commun. Pour faciliter la gestion des API, Apigee complète ces URI bruts avec des noms à afficher et des descriptions. |
| utilisateur de l'API | Synonyme de "développeur d'applications", qui utilise les API créées par un fournisseur d'API. |
| développeur d'API | Ingénieur logiciel dans l'organisation d'un fournisseur d'API qui crée des API. Ces API permettent aux développeurs d'applications (utilisateurs d'API) de créer des applications. |
| package d'API | Ensemble de produits d'API présenté aux développeurs en tant qu'offre groupée et généralement associé à un plan tarifaire. |
| produit d'API | Ensemble de ressources d'API (URI) associé à un forfait et présenté aux développeurs en tant qu'offre groupée. Le produit d'API peut également inclure des métadonnées propres à votre entreprise à des fins de surveillance ou d'analyse. Vous pouvez monétiser une ou plusieurs ressources en les incluant dans des produits d'API, qui peuvent ensuite être regroupés dans un package d'API pour la monétisation. |
| fournisseur d'API | Un fournisseur d'API crée des API (à l'aide d'Edge) que les consommateurs d'API (développeurs d'applications) peuvent utiliser. |
| développeur d'applications | Dans Edge, les développeurs d'applications enregistrent leurs applications auprès d'un fournisseur d'API. C'est ainsi que les développeurs d'applications obtiennent les clés API dont ils ont besoin pour appeler les proxys d'API du fournisseur. |
| applications | Les développeurs accèdent aux ressources de vos produits d'API à l'aide d'applications. Lorsque vous créez une application, vous sélectionnez le produit d'API à inclure et Apigee génère une clé. Chaque application possède une clé unique permettant d'accéder à plusieurs produits d'API. Les applications vous permettent de contrôler l'accès à vos ressources. Pour contrôler l'accès à vos produits d'API, vous pouvez révoquer et actualiser la clé d'une application. Vous pouvez également contrôler l'accès à des groupes de ressources en révoquant ou en supprimant l'accès aux produits dans une application. |
| détails du solde | Dans le cas d'un développeur disposant d'une réserve prépayée, il s'agit du solde de son compte. |
| ajustement clos | Ajustement appliqué dans les documents de facturation publiés. |
| mois de facturation clos | Mois calendaire complet pour lequel les documents de facturation ont été publiés. |
| limite personnalisée | Limite (par exemple, limite du nombre de transactions sur un produit d'API) que vous pouvez configurer explicitement à l'aide de la monétisation. Également appelée limite explicite. |
| plan tarifaire pour les catégories de développeurs | Plan tarifaire qui s'applique à tous les développeurs d'une catégorie spécifique et qui est disponible à l'achat pour tous les développeurs de cette catégorie. |
| plan tarifaire pour les développeurs | Plan tarifaire qui s'applique à un développeur spécifique et qui n'est disponible à l'achat que pour ce développeur. |
| mandataire déclaré | En droit commercial, personne autorisée à agir au nom d'une personne (appelée "mandant") afin d'établir un lien juridique avec un tiers. Dans le cadre de la monétisation, un modèle fiscal peut être établi pour un plan de revenus partagés, de sorte que le fournisseur d'API agit en tant que mandataire déclaré du développeur pour collecter des revenus (et éventuellement des taxes de vente) pour le compte du développeur. |
| modèle fiscal déclaré | Modèle fiscal dans lequel le fournisseur d'API agit en tant que mandataire déclaré du développeur. |
| environnement | Contexte d'exécution pour les API. Une API doit être déployée dans un environnement avant de pouvoir y accéder au moment de l'exécution. Par défaut, les organisations Apigee sont provisionnées avec deux environnements : "test" et "prod". L'environnement "test" sert généralement à déployer des API en phase de test. L'environnement "prod" permet généralement de déployer des API en vue d'une utilisation en production. |
| modèle fiscal hybride | Modèle fiscal dans lequel le fournisseur d'API agit en tant que mandataire déclaré du développeur. Toutefois, le fournisseur d'API paie la taxe de vente perçue auprès de ses clients aux autorités fiscales locales au nom du développeur. |
| limite implicite | Limite (par exemple, limite de réserve prépayée d'un développeur) définie par la monétisation. |
| monétisation | Composant des services de développement Apigee Edge offrant un moyen simple et flexible de monétiser des produits d'API. |
| montant mensuel utilisé | Utilisation totale d'un développeur pour un mois donné, comprenant les frais de configuration, les frais de transaction et les frais récurrents. |
| paiements mensuels | Paiements récurrents effectués par un développeur en fonction des forfaits souscrits. Les plans tarifaires peuvent inclure des frais récurrents facturés à un développeur chaque mois, quelle que soit son utilisation. |
| déclaration de compensation | Document financier indiquant les soldes nets entre les factures et les déclarations de partage des revenus. |
| ajustement ouvert | Ajustement qui n'a pas encore été appliqué dans les documents de facturation publiés. |
| mois de facturation ouvert | Mois calendaire complet pour lequel les documents de facturation "finaux" n'ont pas encore été publiés. |
| organisation | Conteneur pour tous les objets de votre compte Apigee, y compris les API, les produits d'API, les packages d'API, les applications et les développeurs. Un compte utilisateur est requis pour chaque organisation pour laquelle vous pouvez être membre. (La plupart des utilisateurs disposent d'un compte dans une seule organisation.) Vous devez fournir vos identifiants (nom d'utilisateur et mot de passe) et le nom de votre organisation lors de chaque envoi de requête API. |
| catalogue de packages | Liste des packages d'API. Chaque package est répertorié avec ses produits d'API et ses plans tarifaires. |
| réserve prépayée | Montant disponible permettant à un développeur disposant d'une réserve prépayée de payer à l'avance des packages d'API. |
| développeur disposant d'une réserve prépayée | Développeur qui paie à l'avance l'utilisation d'un produit d'API. Les fonds sont déduits du solde du développeur lorsqu'il utilise le produit d'API. Le développeur doit conserver une réserve prépayée suffisante pour acheter le produit d'API. Les développeurs se voient attribuer l'état "pré-paiement" ou "post-paiement" par le fournisseur d'API. |
| règle | Étape de traitement exécutée comme une unité de logique atomique et réutilisable dans un flux d'API. Les règles types incluent les requêtes de routage vers le point de terminaison approprié, la transformation d'un format de message, l'application du contrôle des accès, l'appel de services distants pour obtenir des informations supplémentaires, le masquage des données sensibles auprès des utilisateurs externes, la vérification du contenu des messages pour détecter les menaces potentielles, la mise en cache des réponses courantes pour améliorer les performances, etc. Les règles peuvent être exécutées de manière conditionnelle en fonction du contenu ou du contexte d'un message de requête ou de réponse. Par exemple, une règle de transformation peut être exécutée pour personnaliser un format de réponse si le message de la requête a été envoyé depuis un smartphone. |
| développeur post-payé | Développeur facturé chaque mois (via une facture) pour l'utilisation de produits d'API. Le développeur paie pour l'utilisation des produits d'API conformément aux conditions de paiement définies par le ou les forfaits inclus sur la facture. Les développeurs se voient attribuer l'état "post-paiement" ou "prépaiement" par le fournisseur d'API. |
| prix | Plage de prix possibles pour la commercialisation d'un article. |
| plan tarifaire du tableau des tarifs | Plan tarifaire dans lequel un tarif fixe ou variable est facturé au développeur pour chaque transaction impliquant un produit d'API monétisé. |
| plan tarifaire | Spécification des frais et du partage des revenus pour l'utilisation des produits d'API proposés dans un package d'API monétisé. |
| chemin d'accès à la ressource |
Concept RESTful qui qualifie un URI identifiant le chemin réseau d'une ressource donnée. |
| plan tarifaire du partage des revenus | Plan tarifaire dans lequel le pourcentage de revenus générés pour chaque transaction impliquant un produit d'API monétisé est partagé avec le développeur de l'application qui a envoyé la requête. |
| forfait de partage des revenus et du tableau des tarifs | Plan tarifaire dans lequel le pourcentage de revenus générés pour chaque transaction impliquant un produit d'API monétisé est partagé avec le développeur de l'application qui a envoyé la requête. Des frais fixes ou variables s'appliquent également pour chaque transaction effectuée par le développeur. |
| autofacturation | Document financier généré à la place d'une déclaration de partage des revenus. Il indique le montant dû au développeur et sert de facture au fournisseur d'API pour le compte du développeur. |
| plan tarifaire standard | Plan tarifaire disponible à l'achat pour tous les développeurs. |
| taxes | Total des taxes appliquées à l'utilisation et aux frais d'un développeur. |
| crédit | Action effectuée par un développeur pour ajouter des fonds à sa réserve prépayée. |
| règlement concernant l'enregistrement des transactions | Mécanisme permettant à la monétisation d'enregistrer les paramètres de transaction et les attributs personnalisés. La monétisation doit disposer de ces informations pour effectuer son traitement de monétisation, par exemple en appliquant des plans tarifaires aux requêtes et aux réponses de l'API en fonction des attributs personnalisés enregistrés dans chaque transaction. |
| mandataire non déclaré | Organisation (ou opérateur) prenant part à l'offre sous-jacente d'applications, de sorte qu'elle achète le contenu au nom du développeur (à des fins fiscales uniquement). En tant que mandataire non déclaré, l'organisation (ou l'opérateur) peut collecter et déclarer les taxes dues aux utilisateurs finaux. Ce statut n'est pertinent que pour des raisons fiscales. Le statut juridique du développeur dans la chaîne d'approvisionnement n'est pas affecté. |
| modèle fiscal non déclaré | Modèle fiscal dans lequel le fournisseur d'API déduit la taxe perçue auprès des utilisateurs finaux et la reverse aux autorités fiscales locales. |
| version | Version de l'interface de l'API destinée aux développeurs. Par exemple, pivotaltracker.com/services/v3 ou api.enterprise.apigee.com/v1. Ce terme est différent d'une "révision", qui correspond au package de configuration et de règles regroupées dans un proxy d'API, numéroté et contrôlé par la version. En résumé, les versions s'appliquent aux interfaces d'API et les révisions aux proxys d'API. |