Cykl programowania API

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Każda organizacja ma swój własny cykl życia rozwoju oprogramowania (SDLC). Często konieczne jest zsynchronizowanie wdrażania interfejsu API z tymi samymi procesami, których używasz obecnie do tworzenia, testowania i wdrażania innych aplikacji.

Usługi API udostępniają narzędzia i interfejsy API REST, które umożliwiają zintegrowanie wdrażania i zarządzania proksy API z SDLC organizacji. Typowym zastosowaniem interfejsu API typu REST jest pisanie skryptów lub kodu, które wdrażają za pomocą programów serwery proxy interfejsu API lub przenoszą je z jednego środowiska do drugiego w ramach większego procesu zautomatyzowanego, który wdraża lub przenosi też inne aplikacje. Usługi interfejsu API nie opierają się na żadnych założeniach dotyczących SDLC (ani też innych SDLC). Zamiast tego udostępnia funkcje atomowe, które zespół programistów może koordynować, aby automatyzować i optymalizować cykl życia interfejsu API.

Interfejsy API usług API są opisane w dokumentacji interfejsu API. Zapoznaj się z informacjami o rozpoczynaniu pracy z dokumentacją interfejsu API.

Środowiska

Każda organizacja w Apigee Edge ma co najmniej 2 środowiska wdrożenia dostępne dla proxy interfejsu API: „test” i „prod”. Rozróżnienie między tymi 2 środowiskami jest dowolne – każde z nich jest po prostu identyfikowane na podstawie innego zestawu adresów sieciowych (adresów URL). Celem jest udostępnienie domeny, w której można tworzyć i weryfikować proksy interfejsu API, zanim będzie on udostępniony zewnętrznym deweloperom.

Możesz korzystać z tych środowisk, aby zsynchronizować rozwój proxy API z przetwarzaniem w SDLC. Każde środowisko jest definiowane przez adres sieciowy, co umożliwia rozdzielanie ruchu między proksy API, nad którymi pracujesz, i tymi, do których aplikacje uzyskują dostęp w czasie wykonywania. Adresy sieci dostępne w każdym środowisku są definiowane w zbiorze hostów wirtualnych dostępnych w tym środowisku.

Przychodzące: protokół TLS/SSL serwera jest automatycznie włączony w każdym środowisku. W każdym środowisku zdefiniowane są 2 hosty wirtualne: default i secure. Wartość domyślna definiuje adres HTTP, a bezpieczny – adres HTTP/S z wstępnie skonfigurowanym protokołem TLS/SSL po stronie serwera. W konfiguracji serwera proxy interfejsu API możesz określić, które hosty wirtualne ma nasłuchiwać. Podczas przenoszenia wersji do produkcji zwykle wyłączasz HTTP, usuwając default VirtualHost z konfiguracji serwera proxy interfejsu API.

Na przykład ten punkt końcowy proxy nasłuchuje na porcie HTTP i HTTPS.

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

Usunięcie elementu default VirtualHost z konfiguracji ProxyEndpoint spowoduje utworzenie proxy API, które będzie nasłuchiwać tylko na porcie HTTPS, a nie HTTP.

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

Aby sprawdzić, które hosty wirtualne są dostępne w danym środowisku, w menu głównym interfejsu zarządzania wybierz Środowiska.

Środowiska zapewniają również segregację danych i zasobów. Możesz na przykład skonfigurować różne pamięci podręczne w trybie testowym i produkcyjnym, do których dostęp mają tylko serwery proxy interfejsów API wykonywane w tym środowisku. Dodatkowo klucze API wydane w środowisku testowym nie są ważne w środowisku produkcyjnym i odwrotnie.

Wdrażanie serwerów proxy API w środowiskach

Podczas tworzenia serwera proxy interfejsu API musisz wybrać środowisko, w którym będziesz pracować. Możesz utworzyć nowy serwer proxy interfejsu API w wersji produkcyjnej, ale nie jest to zalecane, ponieważ możesz udostępnić interfejs API deweloperom, zanim będzie gotowy. Zacznij od utworzenia serwera proxy interfejsu API w test, który po przetestowaniu przeniesiesz do prod.

Więcej informacji znajdziesz w artykule o wdrażaniu.

Iteracyjne testowanie

Gdy pracujesz na serwerze proxy interfejsu API, usługi interfejsu API zapisują iteracje konfiguracji jako wersje. Podczas wdrażania serwera proxy interfejsu API wybierasz określoną wersję do wdrożenia. Zwykle wdrażasz najnowszą wersję, a w razie potrzeby przywracasz poprzedni numer wersji. Możesz wybrać, gdzie chcesz wdrożyć te wersje. Możesz na przykład awansować wersję do wersji produkcyjnej, aby umożliwić programistom rozpoczęcie pracy z Twoim interfejsem API. Jednocześnie możesz testować wiele wersji, w których dodajesz funkcje lub dostosowujesz zasady. Gdy wszystko będzie gotowe, możesz wdrożyć nową wersję w środowisku produkcyjnym, zastępując istniejącą w tym środowisku. Korzystając z tej metody, możesz w każdej chwili udostępnić deweloperom wersję roboczą interfejsu API w czasie jego programowania.

Promowanie do środowiska produkcyjnego

Gdy interfejs API proxy zostanie w pełni wdrożony i przetestowany, można go przenieść do środowiska produkcyjnego. Wersja proxy interfejsu API w środowisku testowym zostanie użyta do zastąpienia wersji proxy interfejsu API wdrożonej w środowisku produkcyjnym.

Usługi interfejsu API zapewniają możliwości zapewniające płynne wdrażanie serwerów proxy interfejsu API, co minimalizuje wpływ na aplikacje i użytkowników końcowych podczas procedury wdrażania.

Wdrażanie za pomocą skryptu

Interfejs zarządzania Apigee Edge umożliwia wdrażanie w produkcji serwerów proxy API bezpośrednio z poziomu kreatora serwera proxy API. Jednak w wielu sytuacjach wymagania dotyczące bezpieczeństwa, niezawodności i spójności będą wymagać od zespołów programistów wdrażania procedur skryptów. W tym celu możesz napisać kod i skrypty wywołujące interfejs API REST dostępny przez usługi API.

Zasoby środowiska

Aby mieć większą kontrolę podczas promocji, zalecamy powtarzanie operacji tylko na serwerach proxy interfejsu API w wersji testowej i wprowadzanie jak najmniejszej liczby zmian w serwerach proxy interfejsu API wdrożonych w wersji produkcyjnej.

Aby to zrobić, musisz się upewnić, że niektóre zasoby powiązane z każdym środowiskiem są skonfigurowane w taki sposób, aby mogły pozostać statyczne w konfiguracji serwera proxy interfejsu API.

• Docelowe adresy URL: podczas testowania i w produkcji serwery proxy interfejsu API często wywołują różne adresy URL zaplecza. Konfiguracji serwera docelowego możesz używać do tworzenia konfiguracji TargetEndpoint niezależnych od środowiska. Zapoznaj się z informacjami o równoważeniu obciążenia na serwerach backendu.
• Pamięci podręczne i mapy klucz-wartość: oba zasoby trwałe są ograniczone do środowiska. Sprawdź, czy używane są konwencje nazewnictwa, aby umożliwić serwerom proxy interfejsów API przechowywanie danych bez konieczności wprowadzania zmian w konfiguracji podczas awansowania. Zapoznaj się z artykułem na temat tworzenia i edytowania pamięci podręcznej środowiska.
• Docelowe elementy ServiceCallout: w zależności od środowiska elementy te mogą używać różnych docelowych elementów, np. gdy ServiceCallout w środowisku testowym korzysta z usługi demonstracyjnej. Zapoznaj się z zasadami dotyczącymi objaśnień usługi.

Aby konfiguracje serwera proxy interfejsu API były niezależne od środowiska, możesz też użyć instrukcji warunkowych. Zdania warunkowe utworzone za pomocą zmiennej environment.name można używać do oceny bieżącego środowiska przed wymuszeniem zasady lub przekierowaniem do adresu URL w backendzie.

Więcej informacji znajdziesz w artykule Więcej informacji o wdrożeniu.