Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen
Jede Organisation hat einen eigenen Lebenszyklus für die Softwareentwicklung. Häufig ist es erforderlich, die API-Proxy-Bereitstellung mit den Prozessen zu synchronisieren und auszurichten, die für Back-End-Dienste verwendet werden.
Mit den in diesem Thema beschriebenen Edge API-Methoden können Sie die API-Proxyverwaltung in den SDLC Ihrer Organisation einbinden. Diese API wird häufig verwendet, um Skripts oder Code zu schreiben, die API-Proxys bereitstellen oder API-Proxys von einer Umgebung in eine andere migrieren, als Teil eines größeren automatisierten Prozesses, der auch andere Anwendungen bereitstellt oder migriert.
Die Edge API trifft keine Annahmen über Ihren SDLC (oder die eines anderen Nutzers). Stattdessen stehen atomare Funktionen zur Verfügung, die von Ihrem Entwicklungsteam koordiniert werden können, um Ihren API-Entwicklungslebenszyklus zu automatisieren und zu optimieren.
Umfassende Informationen finden Sie unter Edge-APIs.
Um die Edge API zu verwenden, müssen Sie sich bei Ihren Aufrufen authentifizieren. Dazu können Sie eine der folgenden Methoden verwenden:
- OAuth2 (nur Public Cloud)
- SAML (öffentliche und private Cloud)
- Basic Auth (nicht empfohlen; öffentliche und private Cloud)
Dieses Thema konzentriert sich auf eine Reihe von APIs für die Verwaltung von API-Proxys.
Video:In diesem kurzen Video erfahren Sie, wie Sie eine API bereitstellen.
Mit der API interagieren
Die folgenden Schritte führen Sie durch einfache Interaktionen mit den APIs.
APIs in Ihrer Organisation auflisten
Sie können damit beginnen, alle API-Proxys in Ihrer Organisation aufzulisten. Ersetzen Sie EMAIL:PASSWORD und ORG_NAME jeweils durch die entsprechenden Einträge. Eine Anleitung finden Sie unter Edge-API verwenden.
curl -u EMAIL:PASSWORD \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis
Beispielantwort:
[ "weatherapi" ]
API abrufen
Sie können die Methode GET für jeden API-Proxy in Ihrer Organisation aufrufen. Dieser Aufruf gibt eine Liste aller verfügbaren Versionen des API-Proxys zurück.
curl -u EMAIL:PASSWORD -H "Accept: application/json" \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi
Beispielantwort:
{
"name" : "weatherapi",
"revision" : [ "1" ]
}
Das einzige von dieser Methode zurückgegebene Detail ist der Name des API-Proxys zusammen mit der zugehörigen Überarbeitung, der eine Nummer zugeordnet ist. API-Proxys bestehen aus einem Bundle von Konfigurationsdateien. Überarbeitungen bieten einen einfachen Mechanismus zur Verwaltung von Konfigurationsaktualisierungen während der Iteration. Überarbeitungen werden sequenziell nummeriert. So können Sie eine Änderung rückgängig machen, indem Sie eine frühere Version Ihres API-Proxys bereitstellen. Sie können auch eine Überarbeitung eines API-Proxys in der Produktionsumgebung bereitstellen und dabei neue Versionen des API-Proxys in der Testumgebung erstellen. Wenn Sie bereit sind, können Sie die höhere Version Ihres API-Proxys aus der Testumgebung gegenüber der vorherigen Version des API-Proxys in der Produktumgebung hochstufen.
In diesem Beispiel gibt es nur eine Version, da der API-Proxy gerade erstellt wurde. Wenn sich ein API-Proxy durch den Lebenszyklus der iterativen Konfiguration und Bereitstellung bewegt, erhöht sich die Versionsnummer in Ganzzahlen. Mit direkten API-Aufrufen für die Bereitstellung können Sie optional die Versionsnummer des API-Proxys erhöhen. Manchmal möchten Sie bei geringfügigen Änderungen die Überarbeitung nicht erhöhen.
API-Überarbeitung abrufen
Die API-Version (z. B. api.company.com/v1) sollte sich nur sehr selten ändern. Wenn Sie die API-Version erhöhen, bedeutet dies für Entwickler, dass sich die Signatur der externen Schnittstelle, die von der API angezeigt wird, erheblich geändert hat.
Die API-Proxy-Überarbeitung ist eine erhöhte Zahl, die einer API-Proxy-Konfiguration zugeordnet ist. API Services verwaltet Überarbeitungen Ihrer Konfigurationen, damit Sie eine Konfiguration wiederherstellen können, wenn ein Fehler auftritt. Standardmäßig wird die Version eines API-Proxys bei jedem Import eines API-Proxys mithilfe der API API-Proxy importieren automatisch erhöht. Wenn Sie die Überarbeitung eines API-Proxys nicht erhöhen möchten, verwenden Sie die API Update API-Proxyversion. Wenn Sie für die Bereitstellung Maven verwenden, nutzen Sie die Optionen clean oder update, wie in der Readme-Datei für das Maven-Plug-in beschrieben.
Sie können beispielsweise die Methode GET für API-Proxyversion 1 aufrufen, um eine detaillierte Ansicht zu erhalten.
curl -u EMAIL:PASSWORD -H "Accept:application/json" \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi/revisions/1
Beispielantwort
{
"configurationVersion" : {
"majorVersion" : 4,
"minorVersion" : 0
},
"contextInfo" : "Revision 1 of application weatherapi, in organization {org_name}",
"createdAt" : 1343178905169,
"createdBy" : "andrew@apigee.com",
"lastModifiedAt" : 1343178905169,
"lastModifiedBy" : "andrew@apigee.com",
"name" : "weatherapi",
"policies" : [ ],
"proxyEndpoints" : [ ],
"resources" : [ ],
"revision" : "1",
"targetEndpoints" : [ ],
"targetServers" : [ ],
"type" : "Application"
}
Diese API-Proxy-Konfigurationselemente sind in der Referenz zur API-Proxy-Konfiguration ausführlich dokumentiert.
API in einer Umgebung bereitstellen
Sobald Ihr API-Proxy für den ordnungsgemäßen Empfang und die Weiterleitung von Anfragen konfiguriert ist, können Sie ihn in einer oder mehreren Umgebungen bereitstellen. Normalerweise iterieren Sie API-Proxys in test und stufen die API-Proxy-Überarbeitung auf prod hoch, wenn sie bereit sind. Häufig werden Sie feststellen, dass Sie viel mehr Überarbeitungen eines API-Proxys in der Testumgebung haben. Das liegt hauptsächlich daran, dass Sie in der Produktionsumgebung viel weniger Iterationen ausführen werden.
Ein API-Proxy kann erst aufgerufen werden, wenn er in einer Umgebung bereitgestellt wurde. Nachdem Sie die API-Proxyversion für die Produktion bereitgestellt haben, können Sie die URL prod für externe Entwickler veröffentlichen.
Umgebungen auflisten
Jede Organisation in Apigee Edge hat mindestens zwei Umgebungen: test und prod. Die Unterscheidung ist willkürlich. Ziel ist es, Ihnen einen Bereich zur Verfügung zu stellen, in dem Sie überprüfen können, ob Ihr API-Proxy ordnungsgemäß funktioniert, bevor Sie ihn für externe Entwickler freigeben.
Jede Umgebung ist im Grunde nur eine Netzwerkadresse, sodass Sie den Traffic zwischen den API-Proxys, an denen Sie arbeiten, und denen, auf die Apps während der Laufzeit zugreifen, aufteilen können.
Umgebungen bieten auch die Trennung von Daten und Ressourcen. Sie können beispielsweise verschiedene Caches in der Test- und in der Produktion einrichten, auf die nur API-Proxys zugreifen können, die in dieser Umgebung ausgeführt werden.
Umgebungen in einer Organisation ansehen
curl -u EMAIL:PASSWORD \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments
Beispielantwort
[ "test", "prod" ]
Deployments analysieren
Eine Bereitstellung ist eine Version eines API-Proxys, der in einer Umgebung bereitgestellt wurde. Ein API-Proxy mit dem Status bereitgestellt ist über das Netzwerk unter den im Element <VirtualHost> für diese Umgebung definierten Adressen zugänglich.
API-Proxys bereitstellen
API-Proxys können erst aufgerufen werden, nachdem sie bereitgestellt wurden. API-Dienste stellen RESTful APIs zur Verfügung, mit denen der Bereitstellungsprozess gesteuert wird.
In einer Umgebung kann jeweils nur eine Version eines API-Proxys bereitgestellt werden. Daher muss die Bereitstellung der bereitgestellten Überarbeitung aufgehoben werden. Sie können festlegen, ob das neue Bundle als neue Überarbeitung bereitgestellt oder die vorhandene Überarbeitung überschrieben wird.
Sie sehen die Apigee Edge-Dokumentation.
Rufen Sie die Apigee X-Dokumentation auf. weitere Informationen
Heben Sie zuerst die Bereitstellung der vorhandenen Überarbeitung auf. Geben Sie den Umgebungsnamen und die Versionsnummer des API-Proxys an, dessen Bereitstellung Sie aufheben möchten:
curl -X DELETE \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments \ -u EMAIL:PASSWORD
Stellen Sie dann die neue Überarbeitung bereit. Die neue Version des API-Proxys muss bereits vorhanden sein:
curl -X POST -H "Content-type:application/x-www-form-urlencoded" \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments \ -u EMAIL:PASSWORD
Nahtlose Bereitstellung (keine Ausfallzeiten)
Verwenden Sie den Parameter override für die Bereitstellungsmethode und setzen Sie ihn auf true, um das Risiko von Ausfallzeiten während der Bereitstellung zu minimieren.
Sie können nicht eine Version eines API-Proxys über eine andere bereitstellen. Die Bereitstellung der ersten Instanz muss immer aufgehoben werden. Wenn Sie override auf true setzen, geben Sie an, dass eine Version eines API-Proxys über der aktuell bereitgestellten Version bereitgestellt werden soll. Das Ergebnis ist, dass die Bereitstellungsreihenfolge umgekehrt wird. Die neue Überarbeitung wird bereitgestellt. Sobald die Bereitstellung abgeschlossen ist, wird die Bereitstellung der bereits bereitgestellten Überarbeitung aufgehoben.
Im folgenden Beispiel wird der Wert override festgelegt, indem er als Formularparameter übergeben wird:
curl -X POST -H "Content-type:application/x-www-form-urlencoded" \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/e/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments" \ -d "override=true" \ -u EMAIL:PASSWORD
Sie können die Bereitstellung weiter optimieren, indem Sie den Parameter delay festlegen. Der Parameter delay gibt ein Zeitintervall in Sekunden an, vor dem die Bereitstellung der vorherigen Überarbeitung aufgehoben werden soll. Dies hat zur Folge, dass laufende Transaktionen ein Zeitintervall haben, in dem sie abgeschlossen werden müssen, bevor der API-Proxy ihre Transaktion verarbeitet, deren Bereitstellung aufgehoben wird. Folgendes geschieht mit override=true und dem Parametersatz delay:
- Revision 1 verarbeitet Anfragen.
- Überarbeitung 2 wird parallel bereitgestellt.
- Wenn Überarbeitung 2 vollständig bereitgestellt ist, wird neuer Traffic an Überarbeitung 2 gesendet. Es wird kein neuer Traffic an Überarbeitung 1 gesendet.
- Überarbeitung 1 verarbeitet möglicherweise noch vorhandene Transaktionen. Wenn Sie den Parameter
delayfestlegen (z. B. 15 Sekunden), geben Sie Überarbeitung 15 Sekunden Zeit, um die Verarbeitung vorhandener Transaktionen abzuschließen. - Nach dem Verzögerungsintervall wird die Bereitstellung von Überarbeitung 1 aufgehoben.
curl -X POST -H "Content-type:application/x-www-form-urlencoded" \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/e/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments?delay=15" \ -d "override=true" \ -u EMAIL:PASSWORD
| Suchparameter | Beschreibung |
|---|---|
override |
Der Standardwert ist Legen Sie |
delay |
Damit die Transaktionsverarbeitung für die vorhandene Überarbeitung abgeschlossen werden kann, bevor die Bereitstellung aufgehoben wird, und um die Möglichkeit von Der Standardwert ist 0 Sekunden. Wenn |
Wenn override=true zusammen mit einem delay verwendet wird, können HTTP-5XX-Antworten während der Bereitstellung eliminiert werden. Das liegt daran, dass beide API-Proxy-Überarbeitungen gleichzeitig bereitgestellt werden. Die Bereitstellung der älteren Überarbeitung wird nach der Verzögerung aufgehoben.
Alle Bereitstellungen einer API-Überarbeitung ansehen
Manchmal ist es erforderlich, eine Liste aller derzeit bereitgestellten Versionen eines API-Proxys abzurufen.
curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi/revisions/1/deployments \ -u EMAIL:PASSWORD
{
"aPIProxy" : "weatherapi",
"environment" : [ {
"configuration" : {
"basePath" : "",
"steps" : [ ]
},
"name" : "test",
"server" : [ {
"status" : "deployed",
"type" : [ "message-processor" ],
"uUID" : "90096dd1-1019-406b-9f42-fbb80cd01200"
}, {
"status" : "deployed",
"type" : [ "message-processor" ],
"uUID" : "7d6e2eb1-581a-4db0-8045-20d9c3306549"
}, {
"status" : "deployed",
"type" : [ "router" ],
"uUID" : "1619e2d7-c822-45e0-9f97-63882fb6a805"
}, {
"status" : "deployed",
"type" : [ "router" ],
"uUID" : "8a5f3d5f-46f8-4e99-b4cc-955875c8a8c8"
} ],
"state" : "deployed"
} ],
"name" : "1",
"organization" : "org_name"
}
Die obige Antwort enthält viele Attribute, die für die interne Infrastruktur von Apigee Edge spezifisch sind. Wenn Sie Apigee Edge nicht lokal verwenden, können Sie diese Einstellungen nicht ändern.
Die wichtigen in der Antwort enthaltenen Attribute sind organization, environment, aPIProxy, name und state. Anhand dieser Attributwerte können Sie feststellen, ob eine bestimmte Version eines API-Proxys in einer Umgebung bereitgestellt wurde.
Alle Bereitstellungen in der Testumgebung ansehen
Sie können auch den Bereitstellungsstatus für eine bestimmte Umgebung (einschließlich der Versionsnummer des aktuell bereitgestellten API-Proxys) mit dem folgenden Aufruf abrufen:
curl -u EMAIL:PASSWORD https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/test/deployments
Dies gibt für jede API, die in der Testumgebung bereitgestellt wird, dasselbe Ergebnis wie oben zurück.
Alle Bereitstellungen in Ihrer Organisation ansehen
Verwenden Sie die folgende API-Methode, um eine Liste aller derzeit bereitgestellten Versionen aller API-Proxys in allen Umgebungen abzurufen:
curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/deployments \ -u EMAIL:PASSWORD
Dies gibt für alle API-Proxys, die in allen Umgebungen bereitgestellt werden, das gleiche Ergebnis wie oben zurück.
Da die API RESTful ist, können Sie einfach die Methode POST zusammen mit einer JSON- oder XML-Nutzlast für dieselbe Ressource verwenden, um einen API-Proxy zu erstellen.
Ein Profil für Ihren API-Proxy wird generiert. API-Proxys werden standardmäßig im JSON-Format (JavaScript Object Notation) dargestellt. Unten sehen Sie die JSON-Standardantwort auf die obige POST-Anfrage, durch die ein API-Proxy namens weatherapi erstellt wurde. Es folgt eine Beschreibung jedes Elements im Profil:
{
"configurationVersion" : {
"majorVersion" : 4,
"minorVersion" : 0
},
"contextInfo" : "Revision 1 of application weatherapi, in organization {org_name}",
"createdAt" : 1357172145444,
"createdBy" : "you@yourcompany.com",
"displayName" : "weatherapi",
"lastModifiedAt" : 1357172145444,
"lastModifiedBy" : "you@yourcompany.com",
"name" : "weatherapi",
"policies" : [ ],
"proxyEndpoints" : [ ],
"resources" : [ ],
"revision" : "1",
"targetEndpoints" : [ ],
"targetServers" : [ ],
"type" : "Application"
}
Das generierte API-Proxy-Profil zeigt die vollständige Struktur eines API-Proxys:
APIProxy revision: Die sequenziell nummerierte Iteration der API-Proxy-Konfiguration, die von API-Diensten verwaltet wirdAPIProxy name: Der eindeutige Name des API-ProxysConfigurationVersion: Version der API-Dienste, der die API-Proxy-Konfiguration entsprichtCreatedAt: Zeitpunkt, zu dem der API-Proxy generiert wurde, formatiert im UNIX-ZeitformatCreatedBy: E-Mail-Adresse des Apigee Edge-Nutzers, der den API-Proxy erstellt hatDisplayName: Ein nutzerfreundlicher Name für den API-ProxyLastModifiedAt: Zeitpunkt, zu dem der API-Proxy generiert wurde, formatiert im UNIX-ZeitformatLastModifiedBy: E-Mail-Adresse des Apigee Edge-Nutzers, der den API-Proxy erstellt hatPolicies: Eine Liste von Richtlinien, die diesem API-Proxy hinzugefügt wurdenProxyEndpoints: Eine Liste mit Namen von ProxyEndpunkteResources: Eine Liste von Ressourcen (JavaScript, Python, Java, XSLT), die in diesem API-Proxy ausgeführt werden könnenTargetServers: Eine Liste benannter Zielserver, die mit der Management API erstellt werden können und in erweiterten Konfigurationen für Load-Balancing verwendet werdenTargetEndpoints: Eine Liste mit dem Namen „TargetEndpunkte“
Beachten Sie, dass viele Elemente der API-Proxy-Konfiguration, die mit der einfachen POST-Methode oben erstellt wurde, leer sind. In den folgenden Themen erfahren Sie, wie Sie die Schlüsselkomponenten eines API-Proxys hinzufügen und konfigurieren.
Informationen zu diesen Konfigurationselementen finden Sie auch in der Referenz zur API-Proxy-Konfiguration.
Skripts für die API erstellen
Die Verwendung der Beispiel-API-Proxys, die auf GitHub verfügbar sind, enthalten Shell-Skripts, die das Apigee-Bereitstellungstool umschließen. Wenn Sie das Python-Bereitstellungstool aus irgendeinem Grund nicht verwenden können, können Sie die API direkt aufrufen. Beide Ansätze werden in den folgenden Beispielskripts demonstriert.
Bereitstellungstool umschließen
Prüfen Sie zuerst, ob das Python-Bereitstellungstool in Ihrer lokalen Umgebung verfügbar ist.
Erstellen Sie dann eine Datei für Ihre Anmeldedaten. Die von Ihnen geschriebenen Bereitstellungsskripts importieren diese Einstellungen, sodass Sie die Anmeldedaten für Ihr Konto zentral verwalten können. Im API-Plattformbeispiel heißt diese Datei setenv.sh.
#!/bin/bash org="Your ORG on enterprise.apigee.com" username="Your USERNAME on enterprise.apigee.com" # While testing, it's not necessary to change the setting below env="test" # Change the value below only if you have an on-premise deployment url="https://api.enterprise.apigee.com" # Change the value below only if you have a custom domain api_domain="apigee.net" export org=$org export username=$username export env=$env export url=$url export api_domain=$api_domain
Die obige Datei macht alle Ihre Einstellungen für die Shell-Skripts verfügbar, die das Bereitstellungstool umschließen.
Erstellen Sie nun ein Shell-Skript, das diese Einstellungen importiert und damit das Bereitstellungstool aufruft. Ein Beispiel finden Sie unter API-Plattformbeispiele für Apigee.
#!/bin/bash
source path/to/setenv.sh
echo "Enter your password for the Apigee Enterprise organization $org, followed by [ENTER]:"
read -s password
echo Deploying $proxy to $env on $url using $username and $org
path/to/deploy.py -n {api_name} -u $username:$password -o $org -h $url -e $env -p / -d path/to/apiproxy
Erstellen Sie außerdem ein Script, um die API aufzurufen und zu testen:
#!/bin/bash
echo Using org and environment configured in /setup/setenv.sh
source /path/to/setenv.sh
set -x
curl "http://$org-$env.apigee.net/{api_basepath}"
API direkt aufrufen
Es kann nützlich sein, einfache Shell-Skripts zu schreiben, die das Hochladen und Bereitstellen von API-Proxys automatisieren.
Das folgende Skript ruft die Verwaltungs-API direkt auf. Die Bereitstellung der vorhandenen Version des API-Proxys, den Sie aktualisieren, wird aufgehoben. Anschließend wird im Verzeichnis /apiproxy eine ZIP-Datei mit den Proxykonfigurationsdateien erstellt. Anschließend wird die Konfiguration hochgeladen, importiert und bereitgestellt.
#!/bin/bash #This sets the name of the API proxy and the basepath where the API will be available api=api source /path/to/setenv.sh echo Delete the DS_store file on OSX echo find . -name .DS_Store -print0 | xargs -0 rm -rf find . -name .DS_Store -print0 | xargs -0 rm -rf echo "Enter your password for the Apigee Enterprise organization $org, followed by [ENTER]:" read -s password echo Undeploy and delete the previous revision # Note that you need to explicitly update the revision to be undeployed. # One benefit of the Python deploy tool is that it manages this for you. curl -k -u $username:$password "$url/v1/o/$org/e/$env/apis/$api/revisions/1/deployments" -X DELETE curl -k -u $username:$password -X DELETE "$url/v1/o/$org/apis/$api/revisions/1" rm -rf $api.zip echo Create the API proxy bundle and deploy zip -r $api.zip apiproxy echo Import the new revision to $env environment curl -k -v -u $username:$password "$url/v1/o/$org/apis?action=import&name=$api" -T $api.zip -H "Content-Type: application/octet-stream" -X POST echo Deploy the new revision to $env environment curl -k -u $username:$password "$url/v1/o/$org/e/$env/apis/$api/revisions/1/deployments" -X POST