Cykl programowania API

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

Każda organizacja ma swój własny cykl życia tworzenia oprogramowania (SDLC). Często konieczne jest zsynchronizowanie i dostosowanie wdrażania serwera proxy interfejsu API do procesów, 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ą integrację wdrażania i zarządzania proxy interfejsów API z cyklem życia oprogramowania w Twojej organizacji. Interfejs API typu REST jest często używany do pisania skryptów lub kodu, które programowo wdrażają proxy interfejsów API lub przenoszą je z jednego środowiska do drugiego w ramach większego zautomatyzowanego procesu, który wdraża lub przenosi też inne aplikacje. API Services nie zakłada niczego na temat Twojego cyklu życia oprogramowania (ani cyklu życia oprogramowania żadnej innej osoby). Zamiast tego udostępnia funkcje atomowe, które Twój zespół programistów może koordynować, aby zautomatyzować i zoptymalizować cykl życia tworzenia interfejsu API.

Interfejsy API usług API są opisane w dokumentacji API. Więcej informacji znajdziesz w artykule Pierwsze kroki z dokumentacją API.

Obejrzyj ten film, aby poznać środowiska interfejsów API i cykl tworzenia interfejsów API.

Środowiska

Każda organizacja w Apigee Edge ma co najmniej 2 środowiska wdrażania, które są dostępne dla serwerów proxy interfejsu API: „test” i „prod”. Rozróżnienie między tymi dwoma środowiskami jest arbitralne – każde środowisko jest po prostu identyfikowane przez inny zestaw adresów sieciowych (adresów URL). Celem jest udostępnienie domeny, w której możesz tworzyć i weryfikować serwery proxy interfejsu API, zanim interfejs API zostanie udostępniony zewnętrznym programistom.

Możesz wykorzystać te środowiska do synchronizowania procesu tworzenia proxy interfejsu API z cyklem życia oprogramowania. Każde środowisko jest zdefiniowane przez adres sieciowy, co umożliwia odseparowanie ruchu między serwerami proxy interfejsu API, nad którymi pracujesz, a tymi, do których aplikacje uzyskują dostęp w czasie działania. Adresy sieciowe dostępne w każdym środowisku są zdefiniowane w zestawie VirtualHost dostępnym w tym środowisku.

W przypadku połączeń przychodzących protokół TLS/SSL serwera jest automatycznie włączany w każdym środowisku. W każdym środowisku są predefiniowane 2 hosty wirtualne: default i secure. Domyślny określa adres HTTP, a bezpieczny – adres HTTP/S z wstępnie skonfigurowanym protokołem TLS/SSL po stronie serwera. W konfiguracji proxy interfejsu API określasz, na których hostach wirtualnych ma nasłuchiwać ProxyEndpoint. Podczas promowania do środowiska produkcyjnego zwykle wyłączasz protokół HTTP, usuwając element default VirtualHost z konfiguracji serwera proxy interfejsu API.

Na przykład ten punkt końcowy ProxyEndpoint nasłuchuje protokołów HTTP i HTTPS.

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

Usuwając element default VirtualHost z konfiguracji ProxyEndpoint, tworzysz proxy interfejsu API, które nasłuchuje tylko protokołu HTTPS, a nie HTTP.

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

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

Środowiska zapewniają też odseparowanie danych i zasobów. Możesz na przykład skonfigurować różne pamięci podręczne w środowiskach testowym i produkcyjnym, do których dostęp będą miały tylko serwery proxy interfejsu API działające w tym środowisku. Dodatkowo klucze interfejsu API wydane w środowisku testowym nie są ważne w środowisku produkcyjnym i odwrotnie.

Wdrażanie proxy interfejsów API w środowiskach

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

Więcej informacji znajdziesz w sekcji Informacje o wdrażaniu.

Iteracyjne programowanie w trakcie testów

Podczas pracy nad proxy interfejsu API usługi API zapisują iteracje konfiguracji jako wersje. Podczas wdrażania serwera proxy interfejsu API wybierasz konkretną wersję do wdrożenia. Zazwyczaj wdrażasz najnowszą wersję, a w razie potrzeby przywracasz poprzednią wersję. Możesz wybrać, gdzie chcesz wdrożyć te zmiany. Możesz na przykład promować wersję do środowiska produkcyjnego, aby umożliwić deweloperom rozpoczęcie pracy z interfejsem API. Jednocześnie możesz wprowadzać wiele zmian w wersji testowej, dodając funkcje lub dostosowując zasady. Gdy wszystko będzie gotowe, możesz wdrożyć nową wersję w środowisku produkcyjnym, zastępując istniejącą wersję w tym środowisku. Dzięki tej metodzie możesz zawsze udostępniać programistom aktywną wersję interfejsu API podczas jego tworzenia.

Promowanie do środowiska produkcyjnego

Gdy serwer proxy interfejsu API zostanie w pełni wdrożony i przetestowany, można go przenieść do środowiska „prod”. Wersja proxy interfejsu API w teście zostanie użyta do zastąpienia wersji proxy interfejsu API wdrożonej w środowisku produkcyjnym.

Usługi API zapewniają funkcje, które umożliwiają bezproblemowe wdrażanie proxy interfejsów API, minimalizując wpływ na aplikacje i użytkowników podczas procesu wdrażania.

Wdrożenie skryptu

Interfejs zarządzania Apigee Edge umożliwia wdrażanie serwerów proxy interfejsu API w środowisku produkcyjnym bezpośrednio z poziomu narzędzia do tworzenia serwerów proxy interfejsu API. W wielu sytuacjach jednak wymagania dotyczące bezpieczeństwa, niezawodności i spójności będą wymagać od zespołów deweloperskich tworzenia skryptów procedur wdrażania. Aby to zrobić, możesz napisać kod i skrypty, które wywołują interfejs RESTful API udostępniany przez usługi API.

Zasoby środowiska

Aby mieć większą kontrolę podczas wdrażania promocji, zalecamy iteracyjne testowanie tylko proxy interfejsów API i wprowadzanie jak najmniejszej liczby zmian w proxy interfejsów API wdrożonych w środowisku produkcyjnym.

Aby to zrobić, musisz zadbać o to, aby określone zasoby powiązane z każdym środowiskiem były skonfigurowane w taki sposób, aby mogły pozostać statyczne w konfiguracji serwera proxy interfejsu API.

  • Adresy URL docelowe: często zdarza się, że podczas testowania i wdrażania w środowisku produkcyjnym serwery proxy interfejsu API wywołują różne adresy URL backendu. Konfiguracji TargetServer możesz używać do tworzenia niezależnych od środowiska konfiguracji TargetEndpoint. Zobacz Równoważenie obciążenia na serwerach backendu.
  • Pamięci podręczne i mapy klucz-wartość: oba zasoby trwałe są ograniczone do środowiska. Zadbaj o to, aby używać konwencji nazewnictwa, które umożliwiają serwerom proxy interfejsu API przechowywanie danych bez konieczności wprowadzania zmian w konfiguracji podczas promowania. Zobacz Tworzenie i edytowanie pamięci podręcznej środowiska.
  • Cele wywołania usługi: wywołania usługi mogą używać różnych celów w zależności od środowiska, np. wywołanie usługi w środowisku testowym może korzystać z usługi demonstracyjnej. Zapoznaj się z zasadami dotyczącymi objaśnień do usług.

Aby konfiguracje proxy interfejsu API były niezależne od środowiska, możesz też używać instrukcji warunkowych. Instrukcja warunkowa utworzona za pomocą zmiennej environment.name może służyć do oceny bieżącego środowiska przed wymuszeniem zasad lub przed przekierowaniem do adresu URL na backendzie.

Więcej informacji znajdziesz w artykule Wdrażanie.