Cykl programowania API

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Każda organizacja ma swój własny cykl tworzenia oprogramowania (SDLC). Często konieczne jest synchronizować i dostosować wdrażanie serwera proxy API z tymi samymi procesami, programowania, testowania i wdrażania innych aplikacji.

Usługi API udostępniają narzędzia i interfejsy API typu REST, które umożliwiają integrację wdrożenia serwera proxy interfejsów API do SDLC organizacji. Typowym zastosowaniem interfejsu API typu RESTful jest zapis skrypty lub kod, które automatycznie wdrażają serwery proxy API albo przenoszą takie serwery z jednego w ramach większego zautomatyzowanego procesu, który również wdraża lub migruje inne aplikacji. Usługi API nie składają żadnych założeń na temat Twojego SDLC (ani żadnych innych osób, w tym celu ma znaczenie). Pokazuje jedynie funkcje atomowe, które mogą być koordynowane przez zespół programistów automatyzować i optymalizować cykl tworzenia interfejsów API.

Interfejsy API usług API zostały opisane w dokumentacji API. Zobacz Pobieranie dokumentacji API rozpoczęto.

Środowiska

Każda organizacja w Apigee Edge ma co najmniej 2 dostępne środowiska wdrażania w przypadku serwerów proxy API: „test” i „prod”. Rozróżnienie między tymi 2 środowiskami jest dowolne. — każde środowisko jest po prostu identyfikowane przez inny zestaw adresów sieciowych (URL). celem jest udostępnienie domeny, w której można tworzyć i weryfikować serwery proxy API przed są udostępniane deweloperom zewnętrznym.

Możesz wykorzystać te środowiska do synchronizacji programowania serwera proxy interfejsu API przetworzonego za pomocą SDLC. Każde środowisko jest definiowane przez adres sieciowy, co pozwala rozdzielać ruch między serwery proxy API, nad którymi pracujesz, i te, do których aplikacje uzyskują dostęp w czasie działania; Adresy sieciowe dostępne dla każdego środowiska są określone w zbiorze VirtualHosts dostępnych w tym środowisku.

Przychodzące: protokół TLS/SSL serwera jest automatycznie włączony w każdym środowisku. Dwa hosty wirtualne są wstępnie zdefiniowane w każdym środowisku: default i secure. Wartość domyślna określa Adres HTTP, podczas gdy bezpieczny definiuje adres HTTP/S, ze wstępnie skonfigurowanym TLS/SSL po stronie serwera. W konfigurację serwera proxy interfejsu API, wskażesz VirtualHosty, których punkt końcowy proxy ma nasłuchiwać. Gdy awansujesz do produkcyjnego, zwykle wyłączasz HTTP, usuwając default VirtualHost z konfiguracji serwera proxy interfejsu API.

Na przykład poniższy punkt ProxyEndpoint nasłuchuje w protokole HTTP i HTTPS.

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

Usunięcie obiektu VirtualHost default z konfiguracji ProxyEndpoint spowoduje, utworzyć serwer proxy API, który nasłuchuje tylko przez 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, wybierz Środowiska w menu głównym interfejsu zarządzania.

Ś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 interfejsu API uruchamiane dla środowiska. Dodatkowo klucze interfejsu API wydane w środowisku testowym są nieprawidłowe w 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ć. Ty może utworzyć nowy serwer proxy interfejsu API w środowisku produkcyjnym, ale nie jest to zalecane, ponieważ może to spowodować i udostępniać programistom interfejs API, zanim będzie gotowy. Zacznij od utworzenia serwera proxy interfejsu API w test, który po przeprowadzeniu testów zmienia na prod

Więcej informacji: Informacje o wdrażaniu

Programowanie iteracyjne w fazie testów

Gdy pracujesz na serwerze proxy interfejsu API, Usługi interfejsu API zapisują iteracje konfiguracji jako wersji. Podczas wdrażania serwera proxy interfejsu API wybierasz określoną wersję do wdrożenia. Zwykle wdrażana jest ostatnia wersja, a w razie potrzeby przywraca się poprzednią wersję numer wersji. Możesz wybrać, gdzie chcesz wdrożyć te wersje. Możesz na przykład promować wersja do prod, która pozwoli programistom rozpocząć pracę z Twoim interfejsem API. Jednocześnie możesz być iteracji wielu wersji w ramach testów, w ramach których dodajesz funkcje lub dopracowujesz zasady; Następnie: Gdy wszystko będzie gotowe, możesz wdrożyć nową wersję w środowisku produkcyjnym, zastępując istniejącą tego środowiska. Dzięki tej metodzie możesz zawsze mieć wersję opublikowaną interfejsu API dostępną w dla programistów.

Awans na produkcję

Po pełnym wdrożeniu i przetestowaniu serwera proxy interfejsu API jest gotowy do awansowania na „prod”. Wersja testowanego serwera proxy interfejsu API zostanie użyta do zastąpienia wersji serwera proxy interfejsu API wdrożono w wersji produkcyjnej.

Usługi API zapewniają funkcje umożliwiające bezproblemowe wdrażanie serwerów proxy interfejsów API przy minimalizacji wpływu na aplikacje i użytkowników podczas procedury wdrażania.

Wdrożenie skryptów

Interfejs zarządzania Apigee Edge umożliwia wdrażanie serwerów proxy interfejsu API bezpośrednio z poziomu interfejsu API . Jednak w wielu przypadkach wymagania dotyczące bezpieczeństwa, niezawodności i spójność nakazuje, aby zespoły programistów tworzyły skrypty dotyczące procedur wdrażania. W tym celu możesz: napisać kod i skrypty wywołujące interfejs API typu REST udostępniany przez usługi API.

Zasoby środowiska

Aby uzyskać dodatkową kontrolę podczas promocji, zalecamy iterację wyłącznie z użyciem interfejsu API w testowanych serwerach proxy i w razie potrzeby wprowadzić konieczne zmiany w serwerach proxy API wdrożonych w środowisku produkcyjnym.

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

• Docelowe adresy URL: podczas testowania serwery proxy interfejsów API często wywołują różne adresy URL backendu produkcji. Możesz użyć konfiguracji serwera docelowego, aby utworzyć niezależne od środowiska Konfiguracje docelowego punktu końcowego. Zobacz Równoważenie obciążenia na serwerach backendu.
• Pamięci podręczne i mapy klucz-wartość: oba zasoby są ograniczone przez środowisko. Zalecenia Sprawdź, czy stosowane są konwencje nazewnictwa, aby umożliwić serwerom proxy interfejsów API przechowywanie danych bez konieczności zmian konfiguracji podczas awansowania. Zobacz Tworzenie i edytowanie pamięci podręcznej środowiska.
• Cele objaśnień usługi: objaśnienia dotyczące usługi mogą używać różnych celów w zależności od jeśli na przykład objaśnienie usługi w środowisku testowym korzysta z usługi demonstracyjnej. Zapoznaj się z zasadami dotyczącymi wywołań usługi.

Aby konfiguracje serwera proxy interfejsu API były niezależne od środowiska, możesz też użyć wyciągów. Instrukcja warunkowa utworzona za pomocą zmiennej environment.name może być służy do oceny bieżącego środowiska przed wymuszeniem zasady lub przed przekierowaniem do adresu URL z backendem.

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