Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu
Apigee X. info
In den folgenden Abschnitten werden API-Produkte und verbundene Schlüsselkonzepte vorgestellt.
Was ist ein API-Produkt?
Als API-Anbieter erstellen Sie API-Produkte, um Ihre APIs zu bündeln und für App-Entwickler zur Verfügung zu stellen. Sie können sich API-Produkte als Produktlinie vorstellen.
Ein API-Produkt umfasst insbesondere Folgendes:
- Sammlung von API-Ressourcen (URIs)
- Serviceplan
- Spezifische Metadaten für Ihr Unternehmen zum Monitoring oder zur Analyse (optional)
Die in einem API-Produkt gebündelten API-Ressourcen können aus einer oder mehreren APIs stammen. So können Sie Ressourcen kombinieren, um spezielle Funktionssätze zu erstellen, wie in der folgenden Abbildung dargestellt.
Sie können mehrere API-Produkte erstellen, um Anwendungsfälle zu bedienen, die bestimmte Anforderungen erfüllen. Beispielsweise können Sie ein API-Produkt erstellen, das eine Reihe von Zuordnungsressourcen bündelt, um Entwicklern die einfache Integration von Karten in ihre Anwendungen zu ermöglichen. Außerdem können Sie für jedes API-Produkt unterschiedliche Eigenschaften festlegen, z. B. verschiedene Preisstufen . Beispielsweise können Sie die folgenden API-Produktkombinationen anbieten:
- Ein API-Produkt mit einem niedrigen Zugriffslimit, z. B. 1.000 Anfragen pro Tag zu einem günstigen Preis. Ein zweites API-Produkt, das Zugriff auf dieselben Ressourcen bietet, aber mit einem höheren Zugriffslimit und zu einem höheren Preis.
- Ein kostenloses API-Produkt, das schreibgeschützten Zugriff auf Ressourcen bietet. Ein zweites API-Produkt, das Lese-/Schreibzugriff auf dieselben Ressourcen gegen eine geringe Gebühr bietet.
Außerdem können Sie den Zugriff auf die API-Ressourcen in einem API-Produkt steuern. Sie können beispielsweise Ressourcen bündeln, auf die nur interne Entwickler oder nur zahlende Kunden zugreifen können.
API-Produkte sind der zentrale Mechanismus für die Autorisierung und Zugriffssteuerung für Ihre APIs. In Apigee werden API-Schlüssel bereitgestellt, nicht für APIs selbst, sondern für API-Produkte. Mit anderen Worten: API Schlüssel werden für Gruppen von Ressourcen mit einem angehängten Serviceplan bereitgestellt.
App-Entwickler greifen über die Registrierung ihrer Apps auf Ihre API-Produkte zu, wie unter "Apps registrieren" beschrieben. Wenn eine App versucht, auf ein API-Produkt zuzugreifen, wird die Autorisierung von Apigee zur Laufzeit erzwungen, um Folgendes sicherzustellen:
- Die anfragende App kann auf eine bestimmte API-Ressource zugreifen.
- Die anfragende App hat das zulässige Kontingent nicht überschritten.
- Wenn definiert, stimmen die im API-Produkt definierten OAuth-Bereiche mit denen überein, die mit dem von der App gezeigten Zugriffstoken verbunden sind.
Schlüsselkonzepte
Machen Sie sich mit den folgenden Schlüsselkonzepten vertraut, bevor Sie API-Produkte erstellen.
- API-Schlüssel
- Automatische Genehmigung im Vergleich zu manueller Genehmigung
- Kontingente
- OAuth-Bereiche
- Zugriffsebenen
API-Schlüssel
Wenn Sie die App eines Entwicklers in Ihrer Organisation registrieren, muss die App mit mindestens einem API-Produkt verknüpft werden. Durch das Koppeln einer App mit einem oder mehreren API-Produkten wird die App in Edge einem eindeutigen Consumer-Key zugewiesen.
Der Consumer-Key oder das Zugriffstoken dient als Anfrageanmeldedaten. Der App-Entwickler bettet den Consumer-Key in die App ein. Wenn die App eine Anfrage an eine von Edge gehostete API sendet, übergibt die App den Consumer-Key in der Anfrage so:
- Wenn die API die API-Schlüsselverifizierung verwendet, muss die App den Consumer-Schlüssel direkt übergeben.
- Wenn die API die OAuth-Token-Verifizierung verwendet, muss die App ein Token übergeben, das vom Consumer-Schlüssel abgeleitet wurde.
API-Schlüssel werden nicht automatisch erzwungen. Unabhängig davon, ob der Consumer-Key oder OAuth-Tokens als Anfrageanmeldedaten verwendet werden, validiert der API-Proxy die Anfrageanmeldedaten in Ihren API-Proxys, indem eine VerifyAPIKey-Richtlinie oder eine OAuth/VerifyAccessToken-Richtlinie, in den entsprechenden Ablauf aufgenommen wird. Wenn Sie in Ihrem API-Proxy keine Richtlinie zur Durchsetzung von Anmeldedaten angeben, kann jeder Aufrufer Ihre APIs aufrufen. Weitere Informationen finden Sie unter API-Schlüsselrichtlinie verifizieren.
Um die in der Anfrage übergebenen Anmeldedaten zu prüfen, führt Edge die folgenden Schritte aus:
- Anmeldedaten abrufen, die mit der Anfrage übergeben wurden. Im Fall der OAuth Token-Prüfung verifiziert Edge, dass das Token nicht abgelaufen ist, und ruft dann den Nutzerschlüssel ab, mit dem das Token generiert wurde.
- Liste der API-Produkte abrufen, denen der Consumer-Schlüssel zugeordnet wurde.
- Prüfen, ob der aktuelle API-Proxy im API-Produkt enthalten ist und ob der aktuelle Ressourcenpfad (URL-Pfad) für das API-Produkt aktiviert ist.
- Verifizieren, dass der Consumer-Schlüssel nicht abgelaufen ist oder widerrufen wurde, dass die App nicht widerrufen wurde und dass der App-Entwickler aktiv ist.
Wenn alle oben genannten Prüfungen bestanden wurden, ist die Verifizierung der Anmeldedaten erfolgreich.
Das heißt, Edge generiert automatisch Consumer-Schlüssel, API-Publisher müssen jedoch die Schlüsselprüfung in API-Proxys mithilfe entsprechender Richtlinien erzwingen.
Automatische Genehmigung im Vergleich zu manueller Genehmigung
Standardmäßig werden alle Anfragen zum Abrufen eines Schlüssels für den Zugriff auf ein API-Produkt aus einer Anwendung automatisch genehmigt. Alternativ können Sie das API-Produkt so konfigurieren, dass Schlüssel manuell genehmigt werden müssen. In diesem Fall müssen Sie wichtige Anfragen von allen Apps genehmigen, die das API-Produkt hinzufügen. Weitere Informationen finden Sie unter Apps registrieren und API Schlüssel verwalten.
Kontingente
Mit Kontingenten können Sie Ihre Back-End-Server zugunsten von hohem Traffic schonen und Ihre Produktlinie differenzieren. Sie können beispielsweise Ressourcen mit einem hohen Kontingent als Premium-Produkt bündeln und dasselbe Bündel an Ressourcen mit einem niedrigeren Kontingent als ein Basic-Produkt anbieten. Ein Kontingent kann dabei helfen, Ihre Server vor Überlastung zu schützen, wenn ein Produkt häufig verwendet wird und viele Anfragen erhält.
Informationen zum Konfigurieren von Kontingenten finden Sie unter Kontingent-Richtlinie. Informationen zur Verwendung von Produktkontingenteinstellungen in Kontingentrichtlinien finden Sie im folgenden Community-Artikel: How do the quota settings on an API product interact with quota policies in an API proxy?.
OAuth-Bereiche
Als zusätzliche Sicherheitsmaßnahme können Sie beliebige OAuth-Bereiche als durch Kommas getrennte Liste definieren, die in Zugriffstokens vorhanden sein müssen, die über das Produkt gesendet werden. Wenn Sie ein Produkt erstellen, müssen Sie alle Bereiche kennen, die Ihre Organisation verwendet. Die Bereiche, die Sie einem Produkt hinzufügen , müssen mit vorhandenen Bereichen übereinstimmen, andernfalls ist das Produkt nicht sicher.
Weitere Informationen zur Verwendung von Bereichen mit Edge-OAuth-Richtlinien finden Sie unter Mit OAuth2-Bereichen arbeiten.
Zugriffsebenen
Beim Definieren eines API-Produkts können Sie folgende Zugriffsebenen festlegen.
| Zugriffsebene | Beschreibung |
|---|---|
| Öffentlich | API-Produkte, die allen Entwicklern zur Verfügung stehen. Sie können sie zu integrierten oder Drupal-basierten Entwicklerportalen hinzufügen. |
| Privat oder interne Nutzung | API-Produkte, die für den privaten oder internen Gebrauch bestimmt sind. Hinweis:Zwischen den Zugriffsebenen „Privat“ und „Interne Nutzung“ bestehen keine funktionalen Unterschiede. Wählen Sie das Label aus, das die beabsichtigte Zielgruppe des API-Produkts am besten beschreibt. Für das integrierte Portal können Sie API-Produkte, die privat oder für die interne Nutzung bestimmt sind, hinzufügen und für App-Entwickler bereitstellen. Für Drupal-basierte Entwicklerportale können Sie den Zugriff auf API-Produkte, die privat oder für die interne Nutzung bestimmt sind, auf Ihrem Entwicklerportal verwalten. Weitere Informationen dazu finden Sie in den folgenden Abschnitten:
|