API proxy'si yapılandırma referansı

Apigee Edge belgelerini görüntülüyorsunuz.
. Git: Apigee X belgeleri. bilgi

Apigee Edge ile çalışan bir geliştirici olarak ana geliştirme faaliyetleriniz arasında API'ler veya arka uç hizmetleri için proxy işlevi gören API proxy'lerini yapılandırma. Bu doküman, referans değeri olarak kullanabilirsiniz.

API proxy'leri oluşturmayı öğreniyorsanız Basit bir API derleyin proxy'si aracılığıyla gönderin.

Proxy yapılandırmalarını düzenlemenin en yaygın yolları şunlardır:

• Edge kullanıcı arayüzündeki XML düzenleyiciyi
• Yapılandırmayı indirin ve Yerel proxy yapılandırmalarını geliştirme bölümüne bakın.

Proxy yapılandırmalarının yerel olarak geliştirilmesi

Proxy yapılandırmalarınızı yerel bir makinede düzenleyebilmek için indirebilirsiniz. Zaman işlemi tamamladıktan sonra sonuçları Edge'e yüklüyorsunuz. Bu yaklaşım, proxy'yi entegre etmenize olanak tanır. kaynak denetimi, sürüm oluşturma ve diğer paylaşılan iş akışlarınıza ekleyebilirsiniz. Ayrıca, bir proxy yapılandırması üzerinde yerel olarak çalışırken kendi XML düzenleyicinizi ve doğrulamanızı kullanabilirsiniz. araçlar.

Bu bölümde, mevcut bir proxy yapılandırma dosyasını indirmek, düzenlemek, sonra da dağıtım için Edge'e geri yükleyebilirsiniz. Ayrıca şunu da kullanabilirsiniz: Apigeetool kullanarak yeni bir proxy yapılandırması indirip dağıtın (fetchproxy ve deployproxy komutlarını kullanın.)

Kullanıcı arayüzünü kullanarak bir proxy yapılandırmasını yerel olarak düzenlemek için:

1. Edge kullanıcı arayüzünde geçerli proxy yapılandırmasını indirin. (API Proxy'lerinde Proje > Düzeltmeyi indirin.)
2. Yerel makinenizde yeni bir dizin oluşturun ve indirilen ZIP dosyasını somut olarak ortaya koyar.

   ZIP dosyasını genişletmek için aşağıdaki gibi unzip gibi bir yardımcı program kullanabilirsiniz: örnek gösterilmektedir:

   mkdir myappdir
   unzip ./my-app_app_rev3_2019_04_20.zip -d myappdir

   ZIP dosyasının genişletilmiş içeriği aşağıda açıklanan yapıya benzer olmalıdır: API proxy yapısı.

3. Kaynak dosyaları gerektiği şekilde düzenleyin. Proxy'deki kaynak dosyaların açıklaması için yapılandırma için Yapılandırma dosyaları ve API proxy'sinin dizin yapısı hakkında daha fazla bilgi edinin.

   Örneğin, sağlık izleme hakkında daha fazla bilgi edinmek istiyorsanız /apiproxy/targets/ dizini. Bu dizindeki varsayılan dosya default.xml olarak değişir. Ancak farklı adlara sahip dosyalar farklı olabilir. koşullu hedefler.

   Bu durumda, TargetEndpoint yapılandırma dosyası ve dizini mevcut değilse oluşturabilirsiniz.

4. Proxy yapılandırma dosyalarını düzenlemeyi bitirdikten sonra, değişikliklerinizi kaydettiğinizden emin olun.
5. ZIP dosyalarını genişlettiğinizde oluşturduğunuz yeni dizine (dosyanın kök dizini) geçin genişletilmiş yapılandırma dosyalarını kullanabilirsiniz.

   Örneğin, dosyaları /myappdir dizinine genişlettiyseniz aşağıdaki örnekte gösterildiği gibi bu dizin gereklidir:

   cd myappdir

   Proxy yapılandırma dosyalarınızı yeniden arşivlemeden önce bu dizine geçmeniz gerekir ZIP dosyasına /myappdir dizininin dahil edilmesini istemediğinizden. ZIP dosyasındaki en üst dizin /apiproxy olmalıdır.

6. Yeni veya değiştirilmiş dosyalar da dahil olmak üzere proxy yapılandırma dosyalarını yeniden arşivleyin. URL parametrelerinin Google tarafından nasıl ele alınmasını istediğinizi belirtmek için yardımcı programı (zip gibi) içerir:

   zip my-new-proxy.zip -r .

   ZIP dosyasındaki en üst dizin /apiproxy olmalıdır.

   ZIP dosyasının adına ilişkin özel bir gereklilik yoktur. Örneğin bir web sitesi için düzeltme numarasını artırın veya dosya adında tarihi belirtin, ancak bunu yaptığınızda hata ayıklama veya kaynak kontrolü için kullanışlıdır.

   Edge, yükleme yaptığınızda yeni proxy yapılandırmasının düzeltme numarasını sizin için artırır somut olarak ortaya koyar.

7. Edge kullanıcı arayüzünü kullanarak yeni proxy yapılandırmasını yükleyin. (API Proxy'lerinde Proje > Yeni bir Düzeltme yükleyin.)

   Bundle is invalid. Empty bundle. gibi bir hata alırsanız şunları kontrol edin: ZIP dosyanızın en üst düzey dizini /apiproxy. Doğru değilse proxy yapılandırma dosyalarını genişletmek için kullanabilirsiniz.

   Yeni proxy yapılandırmanızı yükledikten sonra Edge düzeltme numarasını artırır ve Düzeltme Özeti görünümünde görüntülenir.

   Edge, kullanıcı arayüzüyle yükledikten sonra yeni düzeltmeyi sizin için dağıtmaz.

8. Yeni düzeltmenizi dağıtın.

Daha fazla bilgi için bkz. Eğitim: Kullanıcı arayüzünü ve yönetim API'sini kullanarak proxy indirme Apigee Topluluğu.

API proxy'si yapısı

API proxy'si aşağıdaki yapılandırmadan oluşur:

API proxy'si dizin yapısı ve içerikler

Yukarıdaki tabloda yer alan bileşenler, aşağıdaki yapılandırma dosyalarında tanımlanmıştır: dizin yapısı:

Yapılandırma dosyaları ve dizin API proxy'sinin yapısı

Bu bölümde, API proxy'sinin yapılandırma dosyaları ve dizin yapısı açıklanmaktadır.

• Temel Yapılandırma
• ProxyEndpoint
• TargetEndpoint
  • TLS/SSL Hedef Uç Nokta Yapılandırması
• Politikalar
• Akışlar
• Kaynaklar

Temel Yapılandırma

/apiproxy/weatherapi.xml

API proxy'si için temel yapılandırmadır. Bu yapılandırma, API proxy'sinin adını tanımlar. Ad bir kuruluş içinde benzersiz olmalıdır.

Örnek yapılandırma:

<APIProxy name="weatherapi">
</APIProxy>

Temel Yapılandırma Öğeleri

ProxyEndpoint

Aşağıdaki resimde istek/yanıt akışı gösterilmektedir:

/apiproxy/proxies/default.xml

ProxyEndpoint yapılandırması, API'lerin gelen (istemciye yönelik) arayüzünü tanımlar temsil eder. ProxyEndpoint yapılandırması yaptığınızda, varsayılan olarak istemci uygulamalarının ("apps") proxy uygulanan API'yi nasıl çağırması gerektiğini tanımlar.

Aşağıdaki örnek ProxyEndpoint yapılandırması, /apiproxy/proxies:

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <VirtualHost>default</VirtualHost>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

Temel ProxyEndpoint'te gerekli yapılandırma öğeleri şunlardır:

ProxyEndpoint Yapılandırması Elements

RouteRules'u yapılandırma

Adlandırılmış TargetEndpoint, /apiproxy/targets altındaki bir yapılandırma dosyasını RouteRule, ProxyEndpoint tarafından işlendikten sonra bir isteği yönlendirir.

Örneğin, aşağıdaki RouteRule, yapılandırmanın /apiproxy/targets/myTarget.xml:

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

Doğrudan URL Çağrısı

ProxyEndpoint de doğrudan arka uç hizmetini çağırabilir. Doğrudan URL çağrısı, /apiproxy/targets altında TargetEndpoints yapılandırması adlı) İşte bu nedenle TargetEndpoint isteğe bağlı bir API proxy yapılandırmasıdır ancak uygulamada doğrudan çağrı proxy uç noktasının kullanılmasına izin verilmez.

Örneğin, aşağıdaki RouteRule, bir HTTP çağrısı yapar http://api.mycompany.com/v2

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL> 
</RouteRule>

Koşullu Rotalar

RouteRules, çalışma zamanında dinamik yönlendirmeyi desteklemek için zincirlenebilir. Gelen istekler adlandırılmış TargetEndpoint yapılandırmalarına, doğrudan URL'lere veya ikisinin bir kombinasyonuna yönlendirilir HTTP üstbilgilerine, ileti içeriğine, sorgu parametrelerine veya gün, yerel ayar vb.

Koşullu RouteRules, Apigee Edge'deki diğer koşullu ifadeler gibi çalışır. Koşul referansı ve Değişkenler referansı bölümlerine bakın.

Örneğin, aşağıdaki RouteRule kombinasyonu ilk olarak gelen isteği değerlendirir. HTTP üstbilgisinin değeri. routeTo HTTP üstbilgisinde değer varsa TargetEndpoint1, ardından istek, adlı hedef uç noktaya yönlendirilir. TargetEndpoint1. Aksi halde gelen istek http://api.mycompany.com/v2

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

Boş Rotalar

İstek mesajının çalışmadığı senaryoları desteklemek için boş bir RouteRule tanımlanabilir TargetEndpoint'e iletilmesi gerekiyor. Bu, ProxyEndpoint öğesinin tüm düzenlemeleri yapması durumunda Örneğin, harici bir hizmeti çağırmak için JavaScript kullanarak veya API Hizmetleri'ne yapılan bir aramadan veri almak anahtar/değer deposundan yararlanın.

Örneğin, aşağıda boş bir Rota tanımlanır:

<RouteRule name="GoNowhere"/>

Koşullu boş Rotalar faydalı olabilir. Aşağıdaki örnekte, boş bir Rota HTTP üstbilgisi request.header.X-DoNothing şundan farklı bir değere sahip olduğunda yürütülür: null.

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

RouteRules zincirlemesi kullanılabileceğini unutmayın. Bu nedenle, koşullu boş bir Rota genellikle bir bileşeninin bileşenidir.

Koşullu boş Rota'nın pratik bir kullanımı, önbelleğe almayı destekler. Değeri kullanarak ilkesini seçerseniz bir API proxy'sini yapılandırarak Önbellekten bir giriş sunulduğunda boş Rota.

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

TargetEndpoint

TargetEndpoint, ProxyEndpoint'in giden eşdeğeridir. TargetEndpoint, şu şekilde çalışır: bir arka uç hizmetine veya API'ye yönlendirmesi için istek gönderir ve yanıtları alır.

API proxy'sinde herhangi bir TargetEndpoint'in olması gerekmez. ProxyEndpoints, URL'leri çağıracak şekilde yapılandırılabilir doğrudan ekleyebilirsiniz. TargetEndpoints bulunmayan bir API proxy'si genellikle bir arka uç hizmetini doğrudan çağıran veya Java ya da JavaScript'e dokunun.

Hedef Uç Nokta Yapılandırması

/targets/default.xml

TargetEndpoint, Apigee Edge'den başka bir hizmete ya da hizmete giden bağlantıyı tanımlar. gösterir.

Örnek bir TargetEndpoint yapılandırması aşağıda verilmiştir:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

Hedef Uç Nokta Yapılandırması Elements

TargetEndpoint, bir hedefi aşağıdaki yöntemlerden biriyle çağırabilir:

• HTTP(S) çağrıları için HTTPTargetConnection
• Yerel proxy'den proxy'ye zincirleme için LocalTargetConnection
• Edge'de barındırılan bir sayfaya yapılan çağrılar için ScriptTarget Node.js komut dosyası

TargetEndpoint'te bunlardan yalnızca birini yapılandırın.

TLS/SSL Hedef Uç Noktası Yapılandırması

TargetEndpoints genellikle HTTPS bağlantılarını heterojen arka uçla yönetmelidir geliştirmenin harika bir yoludur. Bu nedenle, çeşitli TLS/SSL yapılandırma ayarları desteklenir.

TLS/SSL TargetEndpoint Yapılandırma Öğeleri

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>

<Protocols>
 <Protocol>TLSv1.1</Protocol>
 <Protocol>TLSv1.2</Protocol>
</Protocols>

<CommonName wildcardMatch="true">*.myhost.com</CommonName>

Giden istemci kimlik doğrulamasının etkin olduğu örnek TargetEndpoint

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

Ayrıntılı talimatlar için TLS'yi Yapılandırma uçtan uca (Bulut ve Private Cloud).

Kullanım TLS/SSL değerlerini dinamik olarak ayarlamak için akış değişkenleri

Ayrıca, esnek çalışma zamanı gereksinimlerini desteklemek için TLS/SSL ayrıntılarını dinamik olarak ayarlayabilirsiniz. Örneğin, proxy'niz potansiyel olarak farklı iki hedefe bağlanıyorsa (bir test hedefi ve üretim hedefi içeriyorsa) API proxy'nizin, hangi ortamın ait olduğunu programatik olarak çağrısı ile uygun anahtar deposuna ve güven deposuna referansları dinamik olarak ayarlama. Aşağıdakiler Apigee Topluluğu makalesinde bu senaryo daha ayrıntılı olarak açıklanmakta ve dağıtılabilir API sunulmaktadır. proxy örnekleri: https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html.

Aşağıdaki örnekte, <SSLInfo> etiketinin TargetEndpoint yapılandırmasında; değerler çalışma zamanında (ör. bir Java tarafından Açıklama metni, JavaScript politikası veya Mesaj Atama politikası. Kullanacağınız mesaj değişkenlerini URL'ler ayarlamak istediğiniz değerleri içermelidir.

Değişkenlere yalnızca aşağıdaki öğelerde izin verilir.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

Kullanım TLS/SSL değerlerini dinamik olarak ayarlamak için kullanılan başvurular

HTTPS kullanan bir TargetEndpoint yapılandırırken TLS/SSL sertifikasının süresi dolarsa veya sistem yapılandırmasında yapılan bir değişiklik için sertifikayı güncellemeniz gerekir. İçinde TLS/SSL'yi yapılandırmak için statik değerler kullanarak veya kullanıyorsanız Mesaj İşleyicileri yeniden başlatmanız gerekebilir.

Daha fazla bilgi için bkz. TLS'yi güncelleme sertifikası hakkında daha fazla bilgi edinin.

Ancak isteğe bağlı olarak TargetEndpoint'i bir referans kullanacak şekilde yapılandırabilirsiniz: anahtar deposu veya güven deposu kullanın. Referans kullanmanın avantajı, referans TLS/SSL sertifikasını güncellemeden önce güncellemek için farklı bir anahtar deposuna veya güven deposuna işaret eden yeniden başlatmanız gerekebilir.

Örneğin, aşağıda, anahtar deposuna ilişkin bir referans kullanan bir TargetEndpoint gösterilmektedir:

<SSLInfo> 
    <Enabled>true</Enabled> 
    <ClientAuthEnabled>false</ClientAuthEnabled> 
    <KeyStore>ref://keystoreref</KeyStore> 
    <KeyAlias>myKeyAlias</KeyAlias> 
</SSLInfo>

Şu isimli referansı oluşturmak için aşağıdaki POST API çağrısını kullanın: keystoreref:

curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
-d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

Referans, anahtar deposunun adını ve türünü belirtir.

Referansı görüntülemek için aşağıdaki GET API çağrısını kullanın:

curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/keystoreref -u uname:password

Referansı daha sonra farklı bir anahtar deposuna işaret edecek şekilde değiştirmek için takma adın aşağıdaki PUT çağrısını kullanın:

curl -X PUT -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references/keystoreref \
-d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

TargetEndpoint hedef yük dengeleme ile

TargetEndpoints, üç yük kullanarak birden fazla adlandırılmış TargetServers arasında yük dengelemeyi destekler algoritmalarından biridir.

Ayrıntılı talimatlar için Arka uç genelinde yük dengeleme başlıklı makaleye bakın tıklayın.

Politikalar

API proxy'sindeki /policies dizini, kullanılacak tüm politikaları içerir , API proxy'sindeki Akışlara ekli

Politika Yapılandırma Öğeleri

Politika Eki

Aşağıdaki resimde, API proxy akışlarının yürütme sırası gösterilmektedir:

Yukarıda gösterildiği gibi:

Politikalar, Akışlar'a işleme adımları olarak eklendi. Politikanın adı şu amaçlarla kullanılır: işleme adımı olarak uygulanacak politikayı referans alın. Politika ekinin biçimi şu:

<Step><Name>MyPolicy</Name></Step>

Politikalar, bir Akışa eklendikleri sırayla uygulanır. Örneğin:

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

Politika Eki Yapılandırması Elements

Akışlar

ProxyEndpoint ve TargetEndpoint, istek ve yanıt mesajı için bir ardışık düzen tanımlar bahsedeceğim. İşleme ardışık düzeni, bir istek akışından ve bir yanıt akışından oluşur. Her istek akış ve yanıt akışı, bir veya daha fazla isteğe bağlı "koşullu" şeklinde bir PreFlow'a ayrılır veya "adlandırılmış" öğesidir.

• PreFlow: Her zaman yürütülür. Koşullu Akışlardan önce yürütülür.
• PostFlow: Her zaman yürütülür. Koşullu Akışlardan sonra yürütülür.

Ayrıca ProxyEndpoint'e, yanıt, istekte bulunan istemci uygulamasına döndürülür. Yalnızca MessageLogging politikası ve Google Cloud Logging Uzantısı eklenebilir bu akışa geri döneceğim. PostClientFlow, API proxy gecikmesini azaltır ve web yöneticileri için istemciye yanıt döndürülünceye kadar hesaplanmayan günlük kaydı (örneğin, client.sent.start.timestamp ve client.sent.end.timestamp.Akış kullanılır Yanıtın başlangıç ve bitiş zaman damgaları arasındaki zaman aralığını ölçmek için kullanılır. mesajını alırsınız.

Kısa bir "nasıl yapılır" videosunu izleyin

İleti günlük kaydı politikası eklenmiş bir PostClientFlow örneğini burada bulabilirsiniz.

    ...
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>Message-Logging-1</Name>
            </Step>
        </Response>
    </PostClientFlow>
    ...

API proxy işleme ardışık düzeni, Akışları aşağıdaki sırayla yürütür:

Ardışık Düzen İsteme:

1. Proxy İsteği Ön Akışı
2. Proxy İsteği Koşullu Akışları (İsteğe Bağlı)
3. Proxy İstek Sonrası Akışı
4. Hedef İstek Ön Akışı
5. Hedef İstek Koşullu Akışları (İsteğe Bağlı)
6. Akış Sonrası Hedef İstek

Yanıt Ardışık Düzeni:

1. Hedef Yanıt Ön Akışı
2. Hedef Yanıt Koşullu Akışları (İsteğe Bağlı)
3. Hedef Yanıt PostFlow
4. Proxy Yanıtı Ön Akışı
5. Proxy Yanıtı Koşullu Akışları (İsteğe Bağlı)
6. Proxy Yanıt Sonrası Akışı
7. PostClientFlow Yanıtı (İsteğe Bağlı)

ProxyEndpoint yapılandırmasında yalnızca politika ekleri bulunan Akışların yapılandırılması gerekir TargetEndpoint yapılandırmaları. PreFlow ve PostFlow, yalnızca bir ProxyEndpoint veya PreFlow veya PostFlow sırasında bir politikanın uygulanması gerektiğinde TargetEndpoint yapılandırması bahsedeceğim.

Koşullu akışların aksine PreFlow ve PostFlow öğelerinin sıralaması API proxy'si her birini ardışık düzende uygun bir noktada yürütür. nerede göründüklerinden bağımsız olarak Google Cloud'u da kullanabilirsiniz.

Koşullu Akışlar

ProxyEndpoints ve TargetEndpoints, sınırsız sayıda koşullu akışı (ayrıca (adlandırılmış akışlar) olarak bilinir.

API proxy'si, koşullu akışta belirtilen koşulu test eder ve karşılandığında, koşullu akıştaki işleme adımları API proxy'si tarafından yürütülür. Öğe koşul karşılanmazsa koşullu akıştaki işleme adımları atlanır. Koşullu akışlar, API proxy'sinde tanımlanan sırayla değerlendirilir ve koşulu bu yürütülür.

Koşullu akışlar tanımlayarak işleme adımlarını API proxy'sinde uygulayabilme buna göre:

• İstek URI'si
• HTTP fiili (GET/PUT/POST/DELETE)
• Sorgu parametresi, başlık ve form parametresinin değeri
• Diğer birçok koşul

Örneğin, aşağıdaki koşullu akış, bunun yalnızca isteğin kaynak yolu /accesstoken. /accesstoken yolu, tüm politikalarla birlikte bu akışın yürütülmesine neden olur öğeleri içerir. İstek yolunda sonek yoksa /accesstoken, akış yürütülmez (başka bir koşullu akış olabilir).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>   

Akış Yapılandırma Öğeleri

Adım işleme

Koşullu Akışların sıralı sıralaması Apigee Edge tarafından uygulanır. Koşullu Akışlar yukarıdan aşağıya doğru yürütmektir. Koşulu şu şekilde değerlendirilen ilk koşullu Akış: true yürütülür ve yalnızca bir koşullu Akış yürütülür.

Örneğin aşağıdaki Akış yapılandırmasında, yol son eki, /first veya /second, ThirdFlow yerine Return404 adlı politikayı zorunlu kılıyor.

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

Kaynaklar

"Resources" (Kaynaklar) (API proxy'lerinde kullanılacak kaynak dosyaları) komut dosyaları, kod ve XSL dönüşümleridir akışlara eklenebilecek standart veya Bunlar "Komut Dosyaları" bölümünde proxy düzenleyiciyi kullanabilirsiniz.

Desteklenen dosyalar için Kaynak dosyalar bölümüne bakın kaynak türleri.

Kaynaklar bir API proxy'sinde, ortamda veya kuruluşta depolanabilir. Her durumda, bir bir politikadaki adla referansta bulunuluyor. API Hizmetleri, API'den geçiş yaparak adı çözer ortama ve kuruluş düzeyine göre değişiyor.

Kuruluş düzeyinde depolanan bir kaynağa herhangi bir ortamda Politikalar tarafından referans verilebilir. Ortam düzeyinde depolanan bir kaynağa söz konusu ortamdaki politikalar tarafından referans verilebilir. CEVAP API proxy düzeyinde depolanan kaynağa yalnızca söz konusu API proxy'sindeki Politikalar tarafından referans verilebilir.