<ph type="x-smartling-placeholder"></ph>
Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur
Apigee X-Dokumentation. Weitere Informationen
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 verfügbar zu machen zur Nutzung durch App-Entwickler. 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. Ressourcen zum Erstellen spezieller Feature-Sets, wie in der folgenden Abbildung dargestellt.
Sie können mehrere API-Produkte erstellen, um Anwendungsfälle zu erfüllen, die bestimmte Anforderungen erfüllen. Sie können beispielsweise ein API-Produkt erstellen, das eine Reihe von Zuordnungsressourcen zu ermöglichen es Entwicklern, Karten problemlos in ihre Anwendungen zu integrieren. Darüber hinaus können Sie für jedes API-Produkt unterschiedliche Eigenschaften festlegen, wie etwa unterschiedliche Preise Niveau. Beispielsweise könnten 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 mit Lesezugriff auf Ressourcen. Ein zweites API-Produkt, das gegen eine geringe Gebühr Lese-/Schreibzugriff auf dieselben Ressourcen bietet.
Darüber hinaus können Sie den Zugriff auf die API-Ressourcen in einem API-Produkt steuern. Sie können beispielsweise Ressourcen, auf die nur interne Entwickler oder nur zahlende Kunden zugreifen können.
API-Produkte sind der zentrale Mechanismus für die Autorisierung und Zugriffssteuerung auf 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 Ressourcen-Bundles 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 und manuelle Schlüsselgenehmigung im Vergleich
- 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. Infolge der Kopplung einer App mit einem oder mehreren API-Produkten weist Edge der App einen eindeutigen Verbraucherschlüssel zu.
Der Consumer-Schlüssel oder das Zugriffstoken dient als Anfrageanmeldedaten. Der App-Entwickler bettet den Consumer-Key in die App ein, sodass bei einer Anfrage durch die App an eine von Edge gehostete API sendet die Anwendung den Consumer-Key in der Anfrage auf eine der folgenden Arten:
- 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. Ob der Consumer-Key oder OAuth-Token verwendet wird als Anfrageanmeldedaten verwendet, validiert der API-Proxy die Anfrageanmeldedaten in Ihrem API-Proxys, indem Sie eine VerifyAPIKey-Richtlinie oder eine OAuth/VerifyAccessToken-Richtlinie, an der richtigen Stelle. Wenn Sie keine Richtlinie zur Erzwingung von Anmeldedaten in Ihrem API-Proxy zu verwenden, kann jeder Aufrufer Ihre APIs aufrufen. Weitere Informationen Siehe Richtlinie für API-Schlüssel verifizieren.
Um die in der Anfrage übergebenen Anmeldedaten zu überprüfen, führt Edge die folgenden Schritte aus:
- Anmeldedaten abrufen, die mit der Anfrage übergeben wurden. Im Fall von OAuth Tokenverifizierung überprüft, überprüft Edge, ob das Token nicht abgelaufen ist, und sucht dann nach dem Nutzer Schlüssel, 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.
Fazit: Edge generiert automatisch Verbraucherschlüssel, aber API-Publisher müssen Erzwingen Sie die Schlüsselprüfung in API-Proxys, indem Sie entsprechende Richtlinien verwenden.
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 über eine App automatisch genehmigt. Alternativ können Sie das API-Produkt so konfigurieren, dass Schlüssel manuell genehmigt werden. In diesem Fall müssen Sie wichtige Anfragen von jeder App genehmigen, die das API-Produkt. Weitere Informationen finden Sie unter Apps registrieren und API verwalten Schlüssel.
Kontingente
Kontingente können Ihre Backend-Server bei hohem Traffic schützen 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 Kontingentrichtlinie. Informationen zu Informationen zum Verwenden von Produktkontingenteinstellungen in Kontingentrichtlinien finden Sie im folgenden Community-Artikel <ph type="x-smartling-placeholder"></ph> Wie interagieren die Kontingenteinstellungen eines API-Produkts mit Kontingentrichtlinien in einem API-Proxy?
OAuth-Bereiche
Als zusätzliche Sicherheitsstufe können Sie beliebige OAuth-Bereiche als durch Kommas getrennte Liste, die in Zugriffstokens enthalten sein müssen, die über das Produkt gesendet werden. Wenn Sie ein Produkt erstellen, müssen Sie alle Bereiche kennen, die Ihre Organisation nutzt. Die Bereiche, die Sie einem Produkt hinzufügen müssen mit vorhandenen Bereichen übereinstimmen oder das Produkt ist 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 die folgenden Zugriffsebenen festlegen.
| Zugriffsebene | Beschreibung |
|---|---|
| Öffentlich | API-Produkte, die allen Entwicklern zur Verfügung stehen. Sie können sie integrierten oder Drupal-basierten Entwicklerportalen hinzufügen. |
| Privat oder interne Nutzung | API-Produkte, die für den privaten oder internen Gebrauch bestimmt sind. Hinweis:In Bezug auf Funktion gibt es keine Unterschiede zwischen privaten und nur internen Zugriffsebenen. Wählen Sie das Label aus, das die 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:
|