Lebenszyklus der API-Entwicklung

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 muss die API-Proxybereitstellung mit den gleichen Prozessen synchronisiert und ausgerichtet werden, die Sie derzeit für die Entwicklung, das Testen und das Bereitstellen anderer Anwendungen verwenden.

API-Dienste bieten Tools und RESTful APIs, mit denen Sie die Bereitstellung und Verwaltung von API-Proxys in den SDLC Ihrer Organisation integrieren können. Eine gängige Verwendung der RESTful API besteht darin, Skripts oder Code zu schreiben, mit dem API-Proxys programmatisch bereitgestellt werden, oder die API-Proxys von einer Umgebung in eine andere migrieren, wenn auch andere Anwendungen bereitgestellt oder migriert werden. API-Dienste machen keine Annahmen über Ihren SDLC (oder die von Dritten). Stattdessen werden atomare Funktionen bereitgestellt, die von Ihrem Entwicklungsteam koordiniert werden können, um den API-Entwicklungszyklus zu automatisieren und zu optimieren.

API-APIs sind in der API-Referenz dokumentiert. Siehe Erste Schritte mit der API-Referenz.

In diesem Video erhalten Sie eine Einführung in API-Umgebungen und den API-Entwicklungszyklus.

Umgebungen

Jede Organisation auf Apigee Edge hat mindestens zwei Bereitstellungsumgebungen, die für API-Proxys verfügbar sind: "test" und "prod". Die Unterscheidung zwischen den beiden Umgebungen ist beliebig – jede Umgebung wird einfach durch einen anderen Satz von Netzwerkadressen (URLs) identifiziert. Das Ziel besteht darin, Ihnen eine Domain zur Verfügung zu stellen, in der Sie API-Proxys erstellen und überprüfen können, bevor die API für externe Entwickler freigegeben wird.

Sie können diese Umgebungen verwenden, um die mit Ihrem SDLC verarbeitete API-Proxy-Entwicklung zu synchronisieren. Jede Umgebung wird durch eine Netzwerkadresse definiert, sodass Sie den Traffic zwischen den API-Proxys, an denen Sie arbeiten, und denen, die von Anwendungen zur Laufzeit aufgerufen werden, aufteilen können. Die Netzwerkadressen, die für jede Umgebung verfügbar sind, werden in der Gruppe der VirtualHosts definiert, die in dieser Umgebung verfügbar sind.

Eingehender Server-TLS/SSL ist automatisch für jede Umgebung aktiviert. In jeder Umgebung sind zwei VirtualHosts vordefiniert: default und secure. Mit der Standardeinstellung wird eine HTTP-Adresse definiert, mit der sicheren Einstellung eine HTTP/S-Adresse mit vorkonfiguriertem serverseitigem TLS/SSL. In einer API-Proxykonfiguration legen Sie fest, welche VirtualHosts der ProxyEndpoint überwachen soll. Bei einem Hochstufen von "prod" deaktivieren Sie HTTP normalerweise, indem Sie das VirtualHost default aus der API-Proxykonfiguration entfernen.

Der folgende ProxyEndpoint überwacht beispielsweise HTTP und HTTPS.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Wenn Sie das VirtualHost default aus der ProxyEndpoint-Konfiguration löschen, erstellen Sie einen API-Proxy, der nur HTTPS und nicht HTTP verwendet.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Sie können sehen, welche VirtualHosts in einer Umgebung verfügbar sind, indem Sie im Hauptmenü der Verwaltungsoberfläche die Option Umgebungen auswählen.

Umgebungen bieten auch die Trennung von Daten und Ressourcen. Sie können beispielsweise verschiedene Caches in Test und Produktion einrichten, auf die nur von API-Proxys zugegriffen werden kann, die in dieser Umgebung ausgeführt werden. Darüber hinaus sind in der Testumgebung keine API-Schlüssel gültig, die in der Produktionsumgebung gültig sind und umgekehrt.

API-Proxys in Umgebungen bereitstellen

Wenn Sie einen API-Proxy erstellen, müssen Sie entscheiden, in welcher Umgebung Sie arbeiten werden. Sie können zwar einen neuen API-Proxy für die Produktion erstellen, aber dies wird nicht empfohlen, da Sie Entwicklern eine API zur Verfügung stellen können, bevor sie bereit ist. Erstellen Sie zuerst einen API-Proxy in test, der Sie nach dem Testen hochstufen zu prod können.

Weitere Informationen finden Sie unter Informationen zur Bereitstellung.

Iterative Entwicklung im Test

Wenn Sie an einem API-Proxy arbeiten, speichert API-Dienste Iterationen Ihrer Konfiguration als Überarbeitungen. Wenn Sie einen API-Proxy bereitstellen, wählen Sie eine bestimmte Überarbeitung aus. In der Regel stellen Sie zuerst die neueste Überarbeitung bereit und kehren gegebenenfalls zur vorherigen Überarbeitungsnummer zurück. Sie können auswählen, wo diese Überarbeitungen bereitgestellt werden sollen. Sie können beispielsweise eine Überarbeitung in die Produktion hochstufen, damit Entwickler mit Ihrer API arbeiten können. Gleichzeitig kann es vorkommen, dass Sie mehrere Versionen des Tests iterieren, wenn Sie Funktionen hinzufügen oder Richtlinien optimieren. Wenn Sie bereit sind, können Sie dann die neue Überarbeitung in "prod" bereitstellen und die vorhandene Überarbeitung in dieser Umgebung überschreiben. Mit dieser Methode können Sie Entwicklern während der Entwicklung jederzeit eine Live-Überarbeitung Ihrer API zur Verfügung stellen.

Zu "prod" hochstufen

Wenn ein API-Proxy vollständig implementiert und getestet wurde, kann er zu "prod" hochgestuft werden. Die Version des API-Proxys im Test wird verwendet, um die auf dem Produkt bereitgestellte Version des API-Proxys zu überschreiben.

API-Dienste bieten Funktionen für eine nahtlose Bereitstellung von API-Proxys, die Auswirkungen auf Anwendungen und Endnutzer während des Bereitstellungsprozesses minimieren.

Skriptbereistellung

Mit der Verwaltungsoberfläche von Apigee Edge können Sie API-Proxys direkt aus dem API-Proxy-Builder bereitstellen. In vielen Situationen sind die Anforderungen an Sicherheit, Zuverlässigkeit und Konsistenz erfordern jedoch, dass Entwicklungsteams Skripts bereitstellen. Dazu können Sie Code und Skripts schreiben, die die von API-Diensten bereitgestellte RESTful API aufrufen.

Umgebungsressourcen

Wenn Sie während der Werbeaktion mehr Kontrolle erhalten möchten, sollten Sie nur Test-API-Proxys testen und nur einige Änderungen an den in Produktion bereitgestellten API-Proxys vornehmen.

Dazu müssen Sie dafür sorgen, dass bestimmte mit jeder Umgebung verknüpfte Ressourcen so konfiguriert sind, dass sie in einer API-Proxykonfiguration statisch bleiben können.

  • Ziel-URLs: API-Proxys rufen während des Tests und der Produktion häufig unterschiedliche Back-End-URLs auf. Mit TargetServer-Konfigurationen können Sie umgebungsunabhängige TargetEndpoint-Konfigurationen erstellen. Siehe Load-Balancing auf Back-End-Servern.
  • Caches und Schlüssel/Wert-Zuordnungen: Beide Persistenzressourcen sind nach der Umgebung beschränkt. Sorgen Sie dafür, dass Namenskonventionen verwendet werden, um API-Proxys zum Speichern von Daten zu aktivieren, ohne dass Konfigurationsänderungen während der Hochstufung erforderlich sind. Siehe Umgebungscache erstellen und bearbeiten.
  • ServiceCallout-Ziele: Dienst-Callouts können je nach Umgebung unterschiedliche Ziele verwenden, z. B. verwendet ein ServiceCallout in der Testumgebung einen Demodienst. Siehe Service Callout-Richtlinie.

Um API-Proxykonfigurationen umgebungsunabhängig zu gestalten, können Sie auch bedingte Anweisungen verwenden. Eine mit der Variable environment.name erstellte bedingte Anweisung kann verwendet werden, um die aktuelle Umgebung vor dem Erzwingen einer Richtlinie oder vor dem Routing zu einer URL im Back-End auszuwerten.

Weitere Informationen finden Sie unter Informationen zur Bereitstellung.