Vous consultez la documentation d'Apigee Edge.
Consultez la
documentation Apigee X. en savoir plus
Les sections suivantes présentent les produits d'API et les concepts clés associés.
Qu'est-ce qu'un produit API ?
En tant que fournisseur d'API, vous créez des produits d'API pour regrouper vos API et les mettre à la disposition des développeurs d'applications. Vous pouvez considérer les produits d'API comme votre ligne de produits.
Plus précisément, un produit d'API regroupe les éléments suivants :
- Collection de ressources de l'API (URI)
- Plan de service
- Métadonnées spécifiques à votre entreprise pour la surveillance ou l'analyse (facultatif)
Les ressources d'API regroupées dans un produit d'API peuvent provenir d'une ou de plusieurs API. Vous pouvez donc combiner et utiliser des ressources pour créer des ensembles de fonctionnalités spécialisés, comme illustré dans la figure suivante.
Vous pouvez créer plusieurs produits d'API pour répondre à des cas d'utilisation qui remplissent à des besoins spécifiques. Par exemple, vous pouvez créer un produit d'API qui regroupe un certain nombre de ressources de mappage pour permettre aux développeurs d'intégrer facilement des cartes dans leurs applications. En outre, vous pouvez définir différentes propriétés pour chaque produit d'API, par exemple différents niveaux de tarification. Par exemple, vous pouvez proposer les combinaisons de produits d'API suivantes :
- Un produit d'API offrant une limite d'accès faible, telle que 1 000 requêtes par jour, à un prix attractif. Un deuxième produit d'API offrant un accès aux mêmes ressources, mais avec une limite d'accès plus élevée et un prix plus élevé.
- Un produit d'API sans frais offrant un accès en lecture seule aux ressources. Un deuxième produit d'API offrant un accès en lecture/écriture aux mêmes ressources pour des frais minimes.
De plus, vous pouvez contrôler l'accès aux ressources d'API dans un produit d'API. Par exemple, vous pouvez regrouper les ressources accessibles seulement par les développeurs internes ou seulement par les clients payants.
Les produits d'API constituent le mécanisme central d'autorisation et de contrôle des accès à vos API. Dans Apigee, les clés API sont provisionnées non pas pour les API elles-mêmes, mais pour les produits d'API. En d'autres termes, les clés API sont provisionnées pour des groupes de ressources auxquels un plan de service est associé.
Les développeurs d'applications accèdent à vos produits d'API en enregistrant leurs applications, comme décrit dans la section concernant l'enregistrement d'applications. Lorsqu'une application tente d'accéder à un produit d'API, l'autorisation est appliquée par Apigee lors de l'exécution pour garantir les conditions suivantes :
- L'application à l'origine de la requête est autorisée à accéder à une ressource d'API particulière.
- L'application à l'origine de la requête n'a pas dépassé le quota autorisé.
- S'ils sont définis, les champs d'application OAuth définis dans le produit d'API correspondent à ceux associés au jeton d'accès présenté par l'application.
Comprendre les concepts clés
Passez en revue les concepts clés suivants avant de créer vos produits d'API.
- Clés API
- Approbation automatique ou approbation manuelle de clés
- Quota
- Champs d'application OAuth
- Niveaux d'accès
Clés API
Lorsque vous enregistrez l'application d'un développeur dans votre organisation, celle-ci doit être associée à au moins un produit d'API. Après avoir associé une application à un ou plusieurs produits d'API, Edge attribue à l'application une clé client unique.
La clé client ou le jeton d'accès servent d'identifiants de requête. Le développeur de l'application intègre la clé client dans l'application. Ainsi, lorsque l'application envoie une requête à une API hébergée par Edge, l'application transmet la clé client dans la requête de l'une des manières suivantes:
- Lorsque l'API utilise la validation de clé API, l'application doit transmettre directement la clé client.
- Lorsque l'API utilise la validation des jetons OAuth, l'application doit transmettre un jeton qui a été dérivé de la clé client.
L'application des clés API ne se produit pas automatiquement. Qu'il s'agisse d'utiliser la clé client ou des jetons OAuth comme identifiants de requête, le proxy d'API valide les identifiants de la requête dans vos proxys d'API en incluant une règle VerifyAPIKey ou une règle OAuth/VerifyAccessToken, dans le flux approprié. Si vous n'incluez pas de règle d'application des identifiants dans votre proxy d'API, n'importe quel appelant peut appeler vos API. Pour en savoir plus, consultez la page Règle de vérification des clés API.
Pour vérifier les identifiants transmis dans la requête, Edge effectue les étapes suivantes:
- Récupérer les identifiants transmis avec la requête. Dans le cas de la vérification du jeton OAuth, Edge vérifie que le jeton n'a pas expiré, puis recherche la clé client qui a été utilisée pour générer le jeton.
- Récupérer la liste des produits d'API auxquels la clé client a été associée.
- Vérifier que le proxy d'API actuel est inclus dans le produit d'API et que le chemin d'accès à la ressource actuel (chemin d'URL) est activé sur le produit d'API.
- Vérifier que la clé client n'est pas arrivée à expiration ni révoquée, que l'application n'est pas révoquée et que le développeur d'applications est actif.
Si toutes les vérifications ci-dessus aboutissent, la validation des identifiants réussit.
En fin de compte, Edge génère automatiquement des clés client, mais les éditeurs d'API doivent appliquer la vérification des clés dans les proxys d'API à l'aide de stratégies appropriées.
Approbation automatique ou manuelle
Par défaut, toutes les requêtes d'obtention d'une clé permettant d'accéder à un produit d'API à partir d'une application sont automatiquement approuvées. Vous pouvez également configurer le produit d'API pour approuver les clés manuellement. Dans ce cas, vous devez approuver les requêtes clés de toute application qui ajoute le produit d'API. Pour en savoir plus, consultez la page Enregistrer des applications et gérer des clés API.
Quotas
Les quotas peuvent protéger vos serveurs backend pour accroître le trafic et différencier votre ligne de produits. Par exemple, vous pouvez regrouper des ressources avec un quota élevé en tant que produit premium, puis les utiliser avec un quota inférieur en tant que produit de base. Le quota permet de protéger vos serveurs contre la surcharge si un produit est populaire et reçoit un grand nombre de requêtes.
Pour en savoir plus sur la configuration des quotas, consultez la page Règles de quotas. Pour en savoir plus sur l'utilisation des paramètres de quotas de produits dans les règles de quota, consultez l'article de la communauté qui explique comment les paramètres de quota d'un produit d'API interagissent avec les règles de quota dans un proxy d'API.
Champs d'application OAuth
Pour plus de sécurité, vous pouvez définir n'importe quel champ d'application OAuth, sous la forme d'une liste d'éléments séparés par une virgule. Ceux-ci doivent être présents dans les jetons d'accès envoyés par le produit. Lorsque vous créez un produit, vous devez connaître tous les champs d'application utilisés par votre organisation. Les champs d'application que vous ajoutez à un produit doivent correspondre aux champs d'application existants, ou le produit n'est pas sécurisé.
Pour plus d'informations sur l'utilisation des champs d'application avec les règles OAuth Edge, consultez Utiliser les champs d'application OAuth2.
Niveaux d'accès
Lorsque vous définissez un produit d'API, vous pouvez définir les niveaux d'accès suivants.
| Niveau d'accès | Description |
|---|---|
| Public | Produits d'API disponibles pour tous les développeurs. Vous pouvez les ajouter à des portails des développeurs intégrés ou basés sur Drupal. |
| Privé ou interne seulement | Produits d'API conçus pour une utilisation privée ou interne. Remarque : Il n'existe aucune différence fonctionnelle entre les niveaux d'accès privé et interne seulement. Choisissez le libellé qui décrit le mieux l'audience visée par le produit d'API. Pour le portail intégré, vous pouvez ajouter des produits d'API privés ou internes seulement et les mettre à la disposition des développeurs d'applications, si nécessaire. Pour les portails de développeurs basés sur Drupal, vous pouvez gérer l'accès aux produits d'API privés ou internes uniquement sur votre portail des développeurs, comme décrit dans les sections suivantes:
|