Przeglądasz dokumentację Apigee Edge.
Przejdź do
Dokumentacja Apigee X. informacje.
Serwer proxy interfejsu API to zarządzana fasada usług backendu. Podstawowa konfiguracja serwera proxy interfejsu API składa się z ProxyEndpoint (z definicją adresu URL serwera proxy interfejsu API) oraz parametru TargetEndpoint (zdefiniowano adres URL usługi backendu).
Apigee Edge zapewnia dużą elastyczność w zakresie tworzenia zaawansowanych działań na podstawie tego wzorca. Możesz na przykład dodać zasady kontrolujące sposób, w jaki interfejs API przetwarza żądanie klienta przed wysłaniem do usługi backendu lub manipulowanie odpowiedzią otrzymaną od usługi backendu przed i przekazać go klientowi. Możesz wywoływać inne usługi za pomocą zasad dotyczących wywołań usługi, dodawać niestandardowe zachowanie przez dodanie kodu JavaScript, a nawet utworzyć serwer proxy interfejsu API, który nie wywołuje usługi backendu.
Antywzór
Używanie wywołań usługi do wywoływania usługi backendu na serwerze proxy interfejsu API bez tras do docelowego punktu końcowego jest technicznie wykonalne, ale powoduje utratę danych analitycznych na temat skuteczności za usługę zewnętrzną.
Serwer proxy interfejsu API, który nie zawiera tras docelowych, może być przydatny, gdy nie trzeba przekazywać dalej komunikat żądania do punktu docelowego. Zamiast tego ProxyEndpoint wykonuje wszystkie niezbędne działania o przetwarzaniu danych. Na przykład ProxyEndpoint może pobrać dane z wyszukiwania do interfejsu API usługi API do przechowywania par klucz-wartość i zwracania odpowiedzi bez wywoływania usługi backendu.
Możesz zdefiniować trasę o wartości null na serwerze proxy interfejsu API, jak pokazano poniżej:
<RouteRule name="noroute"/>
Serwer proxy używający trasy o wartości null nie jest miejscem docelowym proxy, bo nie powoduje to wywołania docelowej usługi backendu.
Technicznie jest możliwe dodanie wywołania usługi do niedocelowego serwera proxy w celu wywoływania usługi zewnętrznej, jak pokazano w tym przykładzie:
<!-- /antipatterns/examples/service-callout-no-target-1.xml --> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ProxyEndpoint name="default"> <Description/> <FaultRules/> <PreFlow name="PreFlow"> <Request> <Step> <Name>ServiceCallout-InvokeBackend</Name> </Step> </Request> <Response/> </PreFlow> <PostFlow name="PostFlow"> <Request/> <Response/> </PostFlow> <Flows/> <HTTPProxyConnection> <BasePath>/no-target-proxy</BasePath> <Properties/> <VirtualHost>secure</VirtualHost> </HTTPProxyConnection> <RouteRule name="noroute"/> </ProxyEndpoint>
Serwer proxy nie może jednak dostarczać informacji analitycznych o zachowaniu usługi zewnętrznej (np. o czasie przetwarzania czy odsetku błędów), co utrudnia ocenę wydajności usługi zewnętrznej.
Wpływ
- informacje Analytics dotyczące interakcji z usługą zewnętrzną ( kody błędów, czas odpowiedzi, docelowa skuteczność itp.) jest niedostępna
- Wszelkie konkretne funkcje logiczne wymagane przed wywołaniem wywołania usługi lub po nim są uwzględniane jako stanowią część ogólnej logiki serwera proxy, co utrudnia ich analizę i ponowne wykorzystanie.
Sprawdzona metoda
Jeśli serwer proxy interfejsu API współdziała tylko z jedną usługą zewnętrzną, powinien przestrzegać Wzór projektu, w którym usługa backendu jest zdefiniowana jako docelowy punkt końcowy serwera proxy interfejsu API. Serwer proxy bez reguł routingu do docelowego punktu końcowego nie powinny wywoływać usługi backendu przy użyciu zasady ServiceCallout.
Poniższa konfiguracja proxy działa i działa tak samo jak w przykładzie powyżej, ale jest zgodna z najlepszą metody:
<!-- /antipatterns/examples/service-callout-no-target-2.xml --> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ProxyEndpoint name="default"> <Description/> <FaultRules/> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <PostFlow name="PostFlow"> <Request/> <Response/> </PostFlow> <Flows/> <HTTPProxyConnection> <BasePath>/simple-proxy-with-route-to-backend</BasePath> <Properties/> <VirtualHost>secure</VirtualHost> </HTTPProxyConnection> <RouteRule name="default"> <TargetEndpoint>default</TargetEndpoint> </RouteRule> </ProxyEndpoint>
Używaj wywołań usług do obsługi scenariuszy mashup, w których chcesz wywoływać usługi zewnętrzne przed lub po wywołaniu docelowego punktu końcowego. Objaśnienia dotyczące usługi nie powinny zastępować docelowego punktu końcowego .