API proxy'si yapılandırma referansı

Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. info

Apigee Edge ile çalışan bir geliştirici olarak temel geliştirme faaliyetleriniz, API'ler veya arka uç hizmetleri için proxy görevi gören API proxy'lerini yapılandırmayı içerir. Bu belge, API proxy'leri oluştururken kullanabileceğiniz tüm yapılandırma öğelerinin referansıdır.

API proxy'leri oluşturmayı öğreniyorsanız Basit bir API proxy'si oluşturma konusundan başlamanız önerilir.

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

• Edge kullanıcı arayüzünde XML düzenleyiciyi kullanma
• Yapılandırmayı indirip yerel olarak düzenleyin. Bu işlem, Proxy yapılandırmalarının yerel olarak geliştirilmesi başlıklı makalede açıklanmıştır.

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

Proxy yapılandırmalarınızı indirerek yerel bir makinede düzenleyebilirsiniz. İşiniz bittiğinde sonuçları Edge'e yüklersiniz. Bu yaklaşım, proxy yapılandırmalarını kaynak kontrolü, sürüm oluşturma ve diğer paylaşılan iş akışlarınıza entegre etmenize olanak tanır. Ayrıca, proxy yapılandırması üzerinde yerel olarak çalışarak kendi XML düzenleyicinizi ve doğrulama araçlarınızı kullanabilirsiniz.

Bu bölümde, mevcut bir proxy yapılandırmasını indirmek, düzenlemek ve ardından dağıtım için Edge'e geri yüklemek üzere kullanıcı arayüzünün nasıl kullanılacağı açıklanmaktadır. Yeni bir proxy yapılandırmasını indirmek ve dağıtmak için apigeetool'u da kullanabilirsiniz (sırasıyla fetchproxy ve deployproxy komutlarını kullanarak).

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 mevcut proxy yapılandırmasını indirin. (API Proxies (API Proxy'leri) görünümünde Project > Download Revision'ı (Proje > Revizyonu İndir) seçin.)
2. Yerel makinenizde yeni bir dizin oluşturun ve indirilen ZIP dosyasını bu dizine genişletin.

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

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

   ZIP dosyasının genişletilmiş içeriği, API proxy yapısı bölümünde açıklanan yapıya benzer olmalıdır.

3. Kaynak dosyaları gerektiği gibi düzenleyin. Bir proxy yapılandırmasındaki kaynak dosyaların açıklaması için API proxy'sinin yapılandırma dosyaları ve dizin yapısı başlıklı makaleyi inceleyin.

   Örneğin, API proxy'nizde sağlık izlemeyi etkinleştirmek için /apiproxy/targets/ dizinindeki TargetEndpoint yapılandırma dosyasını düzenleyin. Bu dizindeki varsayılan dosya default.xml'dır. Ancak koşullu hedefler kullanıyorsanız farklı adlara sahip dosyalar olabilir.

   Bu durumda, TargetEndpoint yapılandırma dosyası ve dizini yoksa bunları oluşturun.

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 (genişletilmiş yapılandırma dosyalarının kökü) geçin.

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

   cd myappdir

   /myappdir dizininin ZIP dosyasına dahil edilmesini istemediğiniz için, proxy yapılandırma dosyalarınızı yeniden arşivlemeden önce bu dizine geçmelisiniz. ZIP dosyasındaki en üst düzey 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. Aşağıdaki örnekte gösterildiği gibi zip gibi bir yardımcı program kullanabilirsiniz:

   zip my-new-proxy.zip -r .

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

   ZIP dosya adı için özel bir şart yoktur. Örneğin, revizyon numarasını artırmanız veya dosya adında tarihi belirtmeniz gerekmez. Ancak bu işlemler, hata ayıklama veya kaynak kontrolü için yararlı olabilir.

   Edge, yeni proxy yapılandırmasını yüklediğinizde revizyon numarasını sizin için artırır.

7. Edge kullanıcı arayüzünü kullanarak yeni proxy yapılandırmasını yükleyin. (API Proxies (API Proxyleri) görünümünde Project > Upload a New Revision'ı (Proje > Yeni Bir Revizyon Yükle) seçin.)

   Bundle is invalid. Empty bundle. gibi bir hata alırsanız ZIP dosyanızın üst düzey dizininin /apiproxy olduğundan emin olun. Aksi takdirde, genişletilmiş dizinin kökünden proxy yapılandırma dosyalarınızı yeniden arşivleyin.

   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österir.

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

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

Daha fazla bilgi için Apigee Community'deki Eğitim: Kullanıcı arayüzünü ve yönetim API'sini kullanarak proxy indirme başlıklı makaleyi inceleyin.

API proxy'si yapısı

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

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

Yukarıdaki tablodaki bileşenler, aşağıdaki dizin yapısındaki yapılandırma dosyalarıyla tanımlanır:

API proxy'sinin yapılandırma dosyaları ve dizin 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 TargetEndpoint Yapılandırması
• Politikalar
• Akışlar
• Kaynaklar

Temel Yapılandırma

/apiproxy/weatherapi.xml

API proxy'sinin adını tanımlayan temel yapılandırma. Ad, 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ı, bir API proxy'sinin gelen (istemciye yönelik) arayüzünü tanımlar. ProxyEndpoint'i yapılandırdığınızda, istemci uygulamalarının ("uygulamalar") proxy'li API'yi nasıl çağıracağını tanımlayan bir ağ yapılandırması oluşturursunuz.

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

<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 bir ProxyEndpoint'teki gerekli yapılandırma öğeleri şunlardır:

ProxyEndpoint Yapılandırması Öğeler

RouteRules nasıl yapılandırılır?

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

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

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

Doğrudan URL Çağırma

ProxyEndpoint, arka uç hizmetini doğrudan da çağırabilir. Doğrudan URL çağırma, /apiproxy/targets altındaki tüm adlandırılmış TargetEndpoints yapılandırmalarını atlar. Bu nedenle, TargetEndpoint isteğe bağlı bir API proxy yapılandırmasıdır. Ancak uygulamada ProxyEndpoint'ten doğrudan çağırma önerilmez.

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

<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, HTTP üstbilgilerine, ileti içeriğine, sorgu parametrelerine veya günün saati, yerel ayar gibi bağlamsal bilgilere göre adlandırılmış TargetEndpoint yapılandırmalarına, doğrudan URL'lere ya da ikisinin bir kombinasyonuna yönlendirilebilir.

Koşullu RouteRule'lar, Apigee Edge'deki diğer koşullu ifadeler gibi çalışır. Koşullar referansı ve Değişkenler referansı'na bakın.

Örneğin, aşağıdaki RouteRule kombinasyonu, bir HTTP başlığının değerini doğrulamak için önce gelen isteği değerlendirir. routeTo HTTP başlığında TargetEndpoint1 değeri varsa istek, TargetEndpoint1 adlı TargetEndpoint'e yönlendirilir. Aksi takdirde gelen istek http://api.mycompany.com/v2 adresine yönlendirilir.

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

Null Routes

İstek mesajının TargetEndpoint'e yönlendirilmesi gerekmediği senaryoları desteklemek için boş bir RouteRule tanımlanabilir. Bu, ProxyEndpoint gerekli tüm işlemleri gerçekleştirdiğinde (ör. harici bir hizmeti çağırmak için JavaScript kullanarak veya API hizmetlerinin anahtar/değer deposuna yönelik bir aramadan veri alarak) kullanışlıdır.

Örneğin, aşağıda boş bir rota tanımlanmaktadır:

<RouteRule name="GoNowhere"/>

Koşullu boş rotalar yararlı olabilir. Aşağıdaki örnekte, bir HTTP üst bilgisi request.header.X-DoNothing null dışında bir değere sahip olduğunda yürütülecek şekilde bir boş rota yapılandırılmıştır.

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

RouteRule'ların zincirlenebileceğini unutmayın. Bu nedenle, koşullu bir null Route genellikle koşullu yönlendirmeyi desteklemek için tasarlanmış bir RouteRule kümesinin bir bileşeni olur.

Koşullu boş rota, önbelleğe almayı desteklemek için pratik bir şekilde kullanılabilir. Önbellek politikası tarafından ayarlanan değişkenin değerini kullanarak, bir giriş önbellekten sunulduğunda API proxy'sini boş rota yürütecek şekilde yapılandırabilirsiniz.

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

TargetEndpoint

TargetEndpoint, ProxyEndpoint'in giden eşdeğeridir. TargetEndpoint, bir arka uç hizmeti veya API'ye yönelik istemci olarak işlev görür. İstek gönderir ve yanıt alır.

API proxy'sinin TargetEndpoint'i olması gerekmez. ProxyEndpoints, URL'leri doğrudan çağıracak şekilde yapılandırılabilir. TargetEndpoints'i olmayan bir API proxy'si genellikle bir arka uç hizmetini doğrudan çağıran veya Java ya da JavaScript kullanarak bir hizmeti çağıracak şekilde yapılandırılmış bir ProxyEndpoint içerir.

TargetEndpoint Yapılandırması

/targets/default.xml

TargetEndpoint, Apigee Edge'den başka bir hizmete veya kaynağa giden bağlantıyı tanımlar.

Ö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>

TargetEndpoint Yapılandırması Öğeler

TargetEndpoint, aşağıdaki yöntemlerden biriyle hedefi ç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 Node.js komut dosyasına yapılan çağrılar için ScriptTarget

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

TLS/SSL TargetEndpoint Yapılandırması

TargetEndpoints'in genellikle heterojen arka uç altyapısıyla HTTPS bağlantılarını yönetmesi gerekir. 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 Edge'den arka uca (Cloud ve Private Cloud) yapılandırma başlıklı makaleyi inceleyin.

TLS/SSL değerlerini dinamik olarak ayarlamak için akış değişkenlerini kullanma

Ayrıca, esnek çalışma zamanı gereksinimlerini desteklemek için TLS/SSL ayrıntılarını dinamik olarak ayarlayabilirsiniz. Örneğin, proxy'niz iki farklı hedefle (bir test hedefi ve bir üretim hedefi) bağlantı kuruyorsa API proxy'nizin hangi ortamı çağırdığını programatik olarak algılamasını ve uygun anahtar deposu ile güven deposuna referansları dinamik olarak ayarlamasını sağlayabilirsiniz. Aşağıdaki Apigee Topluluğu makalesinde bu senaryo daha ayrıntılı olarak açıklanmakta ve dağıtılabilir API proxy'si örnekleri verilmektedir: Değişken referansı kullanarak TargetEndpoint için dinamik SSLInfo.

<SSLInfo> etiketinin bir TargetEndpoint yapılandırmasında nasıl ayarlanacağına dair aşağıdaki örnekte, değerler çalışma zamanında (ör. Java Callout, JavaScript politikası veya Assign Message politikası tarafından) sağlanabilir. Ayarlamak istediğiniz değerleri içeren mesaj değişkenlerini kullanın.

Yalnızca aşağıdaki öğelerde değişkenlere 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>

TLS/SSL değerlerini dinamik olarak ayarlamak için referansları kullanma

HTTPS kullanan bir TargetEndpoint yapılandırırken TLS/SSL sertifikasının süresinin dolduğu veya sistem yapılandırmasında yapılan bir değişiklik nedeniyle sertifikayı güncellemeniz gerektiği durumları göz önünde bulundurmanız gerekir. Private Cloud için Edge kurulumunda, TLS/SSL'yi statik değerler veya akış değişkenleri kullanarak yapılandırırken ileti işlemcilerini yeniden başlatmanız gerekebilir.

Daha fazla bilgi için TLS sertifikasını güncelleme başlıklı makaleyi inceleyin.

Ancak, TargetEndpoint'i isteğe bağlı olarak anahtar deposu veya güven deposu için referans kullanacak şekilde yapılandırabilirsiniz. Referans kullanmanın avantajı, TLS/SSL sertifikasını güncellemek için referansı farklı bir anahtar deposuna veya güven deposuna yönlendirecek şekilde güncelleyebilmenizdir. Bu işlem için ileti işlemcilerini yeniden başlatmanız gerekmez.

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

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

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

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

Daha sonra referansı farklı bir anahtar deposuna yönlendirecek şekilde değiştirmek için (takma adın aynı ada sahip olduğundan emin olarak) 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

Hedef yük dengeleme ile TargetEndpoint

TargetEndpoints, üç yük dengeleme algoritması kullanarak birden fazla adlandırılmış TargetServer arasında yük dengelemeyi destekler.

Ayrıntılı talimatlar için Arka uç sunucularında yük dengeleme başlıklı makaleyi inceleyin.

Politikalar

API proxy'sindeki /policies dizini, API proxy'sindeki akışlara eklenebilecek tüm politikaları içerir.

Politika Yapılandırma Öğeleri

Politika Eki

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

Yukarıda gösterildiği gibi:

Politikalar, akışlara işleme adımları olarak eklenir. Politikanın adı, işleme adımı olarak uygulanacak politikaya referans vermek için kullanılır. Politika eklerinin biçimi aşağıdaki gibidir:

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

Politikalar, bir akışa eklendikleri sırayla zorunlu kılınır. Örneğin:

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

Politika Ekleme Yapılandırması Öğeleri

Akışlar

ProxyEndpoint ve TargetEndpoint, istek ve yanıt mesajı işleme için bir işlem hattı tanımlar. İşleme ardışık düzeni, istek akışı ve yanıt akışından oluşur. Her istek akışı ve yanıt akışı; PreFlow, bir veya daha fazla isteğe bağlı "koşullu" ya da "adlandırılmış" akış ve PostFlow olarak alt bölümlere ayrılır.

• 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 bir PostClientFlow ekleyebilirsiniz. Bu akış, yanıt istemde bulunan istemci uygulamasına döndürüldükten sonra yürütülür. Bu akışa yalnızca MessageLogging politikası ve Google Stackdriver Logging Extension eklenebilir. PostClientFlow, API proxy gecikmesini azaltır ve yanıt istemciye döndürülene kadar hesaplanmayan, günlük kaydına alınabilecek bilgileri (ör. client.sent.start.timestamp ve client.sent.end.timestamp) kullanılabilir hale getirir. Bu akış, öncelikli olarak yanıt mesajının başlangıç ve bitiş zaman damgaları arasındaki zaman aralığını ölçmek için kullanılır.

Kısa bir nasıl yapılır videosu izleyin

Aşağıda, ileti günlüğü politikası eklenmiş bir PostClientFlow örneği verilmiştir.

    ...
    <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:

İstek Ardışık Düzeni:

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

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'u
4. Proxy Yanıtı Ön Akışı
5. Proxy yanıtı koşullu akışları (isteğe bağlı)
6. Proxy Yanıtı PostFlow
7. PostClientFlow yanıtı (isteğe bağlı)

Yalnızca politika ekleri olan akışların ProxyEndpoint veya TargetEndpoint yapılandırmalarında yapılandırılması gerekir. PreFlow ve PostFlow yalnızca PreFlow veya PostFlow işleme sırasında bir politikanın uygulanması gerektiğinde ProxyEndpoint veya TargetEndpoint yapılandırmasında belirtilmelidir.

Koşullu akışların aksine, PreFlow ve PostFlow öğelerinin sırası önemli değildir. API proxy'si, Endpoint yapılandırmasında nerede göründüklerine bakılmaksızın her zaman her birini işlem hattında uygun noktada yürütür.

Koşullu akışlar

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

API proxy, koşullu akışta belirtilen koşulu test eder ve koşul karşılanırsa koşullu akıştaki işleme adımları API proxy tarafından yürütülür. 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 karşılanan ilk akış yürütülür.

Koşullu akışlar tanımlayarak bir API proxy'sinde işleme adımlarını aşağıdaki ölçütlere göre uygulayabilirsiniz:

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

Örneğin, aşağıdaki koşullu akış yalnızca istek kaynağı yolu /accesstoken olduğunda yürütüleceğini belirtir. /accesstoken yoluyla gelen tüm istekler, akışa eklenen tüm politikalarla birlikte bu akışın yürütülmesine neden olur. İstek yolunda /accesstoken soneki yoksa akış yürütülmez (başka bir koşullu akış yürütülebilir).

<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ı olarak düzenlenmesi Apigee Edge tarafından zorunlu kılınır. Koşullu akışlar yukarıdan aşağıya doğru yürütülür. Koşulu true olarak değerlendirilen ilk koşullu akış 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, /first veya /second yol sonekini içermeyen tüm gelen istekler ThirdFlow'nin yürütülmesine neden olarak Return404 adlı politikayı zorunlu kılar.

<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

"Kaynaklar" (API proxy'lerinde kullanılacak kaynak dosyaları), politikalar kullanılarak Akışlara eklenebilen komut dosyaları, kod ve XSL dönüşümleridir. Bunlar, yönetim kullanıcı arayüzündeki API proxy düzenleyicisinin "Komut dosyaları" bölümünde görünür.

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

Kaynaklar bir API proxy'sinde, ortamda veya kuruluşta saklanabilir. Her durumda, bir kaynak politikada adıyla referans verilir. API Hizmetleri, API proxy'sinden ortama ve kuruluş düzeyine geçerek adı çözer.

Kuruluş düzeyinde depolanan bir kaynağa herhangi bir ortamdaki politikalar tarafından referans verilebilir. Ortam düzeyinde depolanan bir kaynağa, söz konusu ortamdaki politikalar tarafından başvurulabilir. API proxy düzeyinde depolanan bir kaynak yalnızca söz konusu API proxy'sindeki politikalar tarafından referans alınabilir.