Cette page s'applique à Apigee et à Apigee hybrid.
Consultez la documentation d'Apigee Edge.
Les sections suivantes présentent les produits d'API et les concepts associés tels que les quotas et les clés API.
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 une ou plusieurs opérations. Une opération spécifie un proxy d'API et des chemins de ressources accessibles par ce proxy. Une opération peut également limiter l'accès par des méthodes HTTP et par quota.
.Les produits d'API constituent le mécanisme central du contrôle des accès à vos API. En définissant un ou plusieurs produits d'API dans une application de développeur, vous pouvez limiter l'accès aux proxys avec une clé 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 lots d'opérations qui définissent une gamme de produits ou un plan de service spécifique.
Cas d'utilisation courants
Vous pouvez créer plusieurs produits d'API contenant des opérations pour répondre à des cas d'utilisation spécifiques. Par exemple, vous pouvez créer un produit d'API qui regroupe un certain nombre d'opérations contenant des ressources de mappage pour permettre aux développeurs d'intégrer facilement des mappages dans leurs applications.
Par ailleurs, vous pouvez utiliser des produits d'API pour définir des critères basés sur la tarification tels que les suivants :
Le nombre de requêtes :
- Premium : nombre illimité de requêtes par jour
- Basic : jusqu'à 1 000 requêtes par jour
- Free : jusqu'à 100 demandes par jour
Ou le niveau d'accès :
- Premium : lecture, écriture, mise à jour et suppression
- Basic : lecture et mise à jour
- Free : lecture seule
Ou une combinaison de ces deux critères :
- Extra Premium : lecture et écriture illimitées
- Premium : lecture et écriture jusqu'à 1 000 requêtes par jour
- Basic : accès en lecture et en écriture jusqu'à 100 fois par jour
- Free : lecture jusqu'à 1 000 fois par jour
- Free : accès en lecture seule limité à 100 requêtes par jour
Conditions requises
Les produits d'API faisant partie du paiement à l'usage doivent inclure:
- Proxys extensibles créés avec des hooks de flux ou
- Règles extensibles, telles que VerifyAPIKey ou OAuthv2
Opérations
Une opération est un groupe d'attributs qui limitent l'accès à un ou plusieurs proxys d'API en fonction de critères tels que le chemin d'accès à la ressource, la méthode HTTP et le quota. Une opération comprend les attributs suivants :
| Attribute | nécessaire | Description |
|---|---|---|
| proxy d'API | Obligatoire | Chaque groupe d'opérations doit spécifier un proxy d'API. Un seul proxy est autorisé par groupe d'opérations. |
| Service à distance | Variable | Requis seulement si vous installez et prévoyez d'utiliser Apigee Adapter for Envoy. |
| Chemin d'accès à la ressource | Obligatoire | Chaque groupe d'opérations doit spécifier un ou plusieurs chemins de ressources. Les chemins de ressources d'une opération limitent l'accès à des ressources spécifiques sur un proxy d'API (un chemin de ressource est la partie d'une URL de requête de proxy d'API située après le chemin de base du proxy). |
| Méthode HTTP | Facultatif | Vous pouvez également limiter l'accès à un proxy via une méthode HTTP. Par exemple, si vous spécifiez les méthodes GET et POST pour un groupe d'opérations, seules les requêtes HTTP GET et POST peuvent accéder au proxy pour le chemin d'accès à la ressource spécifié. Si aucune méthode n'est spécifiée, toutes les méthodes sont autorisées. |
| Quota | Facultatif | Vous pouvez spécifier un quota pour le groupe d'opérations. Le quota spécifié dans un groupe d'opérations est prioritaire par rapport à un quota au niveau du produit d'API, s'il est spécifié. |
| Attributs personnalisés | Facultatif | Les attributs personnalisés sont utiles pour les métriques, la surveillance ou les cas où vous souhaitez stocker des informations supplémentaires avec un produit d'API auxquelles vous pourrez accéder ou que vous pourrez récupérer ultérieurement. Les attributs personnalisés associés à une opération existent en plus des attributs personnalisés au niveau du produit d'API et sont accessibles dans l'environnement d'exécution sous forme de variables de flux avec le préfixe apiproduct.operation.attributes.
|
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. Dans le cadre de l'association d'une application à un ou plusieurs produits d'API, Apigee attribue à l'application une clé client unique. Consultez également la section Contrôler l'accès à vos API en enregistrant des applications.
La clé client ou le jeton d'accès servent d'identifiants de requête. Le développeur d'applications intègre la clé client dans l'application. Ainsi, lorsque l'application envoie une requête à une API hébergée par Apigee, 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 utilise 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 configuration de règle VerifyAccessToken (consultez la page règle OAuthv2) 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 valider les identifiants transmis dans la requête, Apigee effectue les étapes suivantes :
- Récupérer les identifiants transmis avec la requête. Dans le cas de la validation du jeton OAuth, Apigee vérifie que le jeton n'est pas arrivé à expiration, puis recherche la clé client ayant é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érifiez que le proxy d'API actuel est inclus dans le produit d'API si le chemin d'accès à la ressource actuel (le chemin d'URL) est activé sur le produit d'API et, s'il est inclus dans le produit, que la requête utilise un verbe HTTP spécifié.
- Vérifiez que le quota, s'il est spécifié, n'a pas été dépassé.
- 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 résumé, Apigee 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 en utilisant les règles appropriées.
Approbation des clés
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 de manière à approuver les clés manuellement. Le paramètre pour cela est décrit dans la section Gérer les produits API. Dans ce cas, vous devez approuver les requêtes clés de toute application qui ajoute le produit d'API. Pour plus d'informations, consultez la section Contrôler l'accès à vos API en enregistrant des applications.
Quotas
Les quotas peuvent protéger vos serveurs de backend contre les variations de trafic élevées et différencier votre gamme de produits. Par exemple, vous pouvez regrouper les ressources avec un quota élevé en tant que produit premium, et utiliser le même lot avec un quota inférieur comme produit de base. Les quotas permettent d'éviter que vos serveurs ne soient surchargés si un produit est populaire et reçoit un grand nombre de requêtes en peu de temps.
Vous pouvez spécifier un quota qui s'applique à tous les proxys d'API inclus dans le produit d'API, ou bien spécifier des quotas au niveau des opérations. Un quota spécifié dans une opération est prioritaire sur un quota défini au niveau du produit d'API.
La définition de limites de quota pour un produit d'API n'applique pas automatiquement de quotas. Il s'agit simplement d'une limite par défaut pouvant être référencée dans les règles de quota. Voici quelques avantages liés à la définition d'un quota sur le produit pour que les règles de quota puissent le référencer :
- Utilisez une règle de quota pour appliquer un paramètre uniforme à tous les proxys d'API d'un produit d'API.
- Si vous modifiez les paramètres de quota du produit d'API au moment de l'exécution, les règles de quota font automatiquement référence aux nouveaux paramètres de quota.
Pour en savoir plus, consultez les ressources suivantes :
- Règle de quota
- Comment les paramètres de quota d'un produit API interagissent-ils avec les règles de quota dans un proxy d'API ?
Champs d'application OAuth
Vous pouvez définir des champs d'application OAuth en tant que liste d'éléments séparés par une virgule qui doivent être présents dans les jetons d'accès associés au produit. Pour en savoir plus sur l'utilisation des champs d'application avec les règles OAuth Apigee, consultez la page 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. |
Private ou Internal only |
Produits d'API conçus pour une utilisation privée ou interne.
Pour le portail intégré, vous pouvez ajouter des produits d'API Pour les portails des développeurs Drupal, vous pouvez gérer l'accès aux produits d'API
|