API proxy'si yapılandırma referansı

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

Apigee Edge ile çalışan bir geliştirici olarak ana geliştirme faaliyetleriniz, API'ler veya arka uç hizmetleri için proxy işlevi gören API proxy'lerinin yapılandırılmasını içerir. Bu belge, API proxy'si 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 konusuyla başlamanız önerilir.

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

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

Proxy yapılandırmalarınızı yerel bir makinede düzenleyebilmek için indirebilirsiniz. İşlemi tamamladığınızda sonuçları Edge'e yüklersiniz. Bu yaklaşım, proxy yapılandırmalarını kaynak denetimi, sürüm oluşturma ve diğer paylaşılan iş akışlarınıza entegre etmenizi sağlar. Ayrıca, yerel olarak bir proxy yapılandırması üzerinde ç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ın indirilmesi, düzenlenmesi ve dağıtım için tekrar Edge'e yüklenmesi için kullanıcı arayüzünün nasıl kullanılacağı açıklanmaktadır. Yeni bir proxy yapılandırması indirmek ve dağıtmak için (sırasıyla fetchproxy ve deployproxy komutlarını kullanarak) Apigeetool aracını da kullanabilirsiniz.

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

  1. Edge kullanıcı arayüzündeki mevcut proxy yapılandırmasını indirin. (API Proxy'leri görünümünde, Proje > Düzeltmeyi İndir'i 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ında açıklanan yapıya benzer olmalıdır.

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

    Örneğin, API proxy'nizde durum izleme özelliğini etkinleştirmek için /apiproxy/targets/ dizininde TargetEndpoint yapılandırma dosyasını düzenleyin. Bu dizindeki varsayılan dosya default.xml olsa da koşullu hedefler kullanırsanı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 tamamladığınızda 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çiş yapın.

    Örneğin, dosyaları /myappdir dizinine genişlettiyseniz aşağıdaki örnekte gösterildiği gibi ilgili dizinle değiştirin:

    cd myappdir

    /myappdir dizininin ZIP dosyasına dahil edilmesini istemediğinizden, proxy yapılandırma dosyalarınızı yeniden arşivlemeden önce bu dizine geçmeniz gerekir. ZIP dosyasının en üst düzey dizini /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ının en üst düzey dizini /apiproxy olmalıdır.

    ZIP dosyası adı için özel bir gereksinim yoktur. Örneğin, düzeltme numarasını artırmanız veya dosya adında tarihi belirtmeniz gerekmez, ancak bunu yapmak hata ayıklama veya kaynak kontrolü için yararlı olabilir.

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

  7. Edge kullanıcı arayüzünü kullanarak yeni proxy yapılandırmasını yükleyin. (API Proxy'leri görünümünde, Proje > Yeni Bir Düzeltme Yükle'yi seçin.)

    Bundle is invalid. Empty bundle. gibi bir hata alırsanız ZIP dosyanızın en üst düzey dizininin /apiproxy olduğundan emin olun. Değilse genişletilmiş dizinin kök dizininden 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 bunu Düzeltme Özeti görünümünde görüntüler.

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

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

Daha fazla bilgi için Apigee Topluluğu'ndaki Eğitim: Kullanıcı arayüzü ve yönetim API'sini kullanarak proxy indirme bölümüne göz atın.

API proxy'si yapısı

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

Temel Yapılandırma API proxy'si için birincil yapılandırma ayarları. Temel Yapılandırma bölümüne bakın.
ProxyEndpoint Yapılandırması Gelen HTTP bağlantısı (uygulamaları Apigee Edge'e istemeden), istek ve yanıt akışları ile politika ekleri için ayarlar. ProxyEndpoint sayfasına göz atın.
TargetEndpoint Yapılandırması Giden HTTP bağlantısı (Apigee Edge'den arka uç hizmetine), istek ve yanıt akışları ve politika ekleri için ayarlar. Daha fazla bilgi için TargetEndpoint sayfasını inceleyin.
Akışlar Politikaların eklenebileceği ProxyEndpoint ve TargetEndpoint istek ve yanıt ardışık düzenleri. Akışlar bölümünü inceleyin.
Politikalar Apigee Edge politika şemalarına uygun olan, XML biçimli yapılandırma dosyaları. Politikalar'a bakın.
Kaynaklar Özel mantık yürütmek için politikalar tarafından başvurulan komut dosyaları, JAR dosyaları ve XSLT dosyaları. Kaynaklar bölümüne bakın.

API proxy dizin yapısı ve içeriği

Yukarıdaki tabloda yer alan bileşenler, aşağıdaki dizin yapısındaki yapılandırma dosyaları tarafından tanımlanır:

apiproxy'nin kök olduğu dizin yapısını gösterir. apiproxy dizininin doğrudan altında, weatherapi.xml dosyasının yanı sıra politikalar, proxy'ler, kaynaklar ve hedef dizinleri bulunur.

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

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

Temel Yapılandırma

/apiproxy/weatherapi.xml

API proxy'sinin adını tanımlayan bir API proxy'si için 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

Ad Açıklama Varsayılan Zorunlu mu?
APIProxy
name Bir kuruluş içinde benzersiz olması gereken API proxy'sinin adı. Bu adda kullanmanıza izin verilen karakterler aşağıdakilerle sınırlıdır: A-Za-z0-9_- Yok Evet
revision API proxy yapılandırmasının düzeltme numarası. Apigee Edge, API proxy'sinin mevcut düzeltmesini otomatik olarak izlediği için düzeltme numarasını açıkça belirtmeniz gerekmez. Yok Hayır
ConfigurationVersion Bu API proxy'sinin uyduğu API proxy yapılandırma şemasının sürümü. Şu anda desteklenen tek değer anaSürüm 4 ve minörSürüm 0'dır. Bu ayar, gelecekte API proxy biçiminin geliştirilmesi için kullanılabilir. 4.0 Hayır
Description API proxy'sinin metin halinde bir açıklaması. Sağlanması durumunda açıklama, Edge yönetim kullanıcı arayüzünde görüntülenir. Yok Hayır
DisplayName API proxy yapılandırmasının name özelliğinden farklı olabilecek, kullanımı kolay bir ad. Yok Hayır
Policies Bu API proxy'sinin /policies dizinindeki politikaların listesi. Normalde bu öğeyi yalnızca API proxy'si Edge yönetim kullanıcı arayüzü kullanılarak oluşturulduğunda görürsünüz. Bu, API proxy'sinin içeriğine dair görünürlük sağlamak üzere tasarlanmış bir "manifest" ayarıdır. Yok Hayır
ProxyEndpoints Bu API proxy'sinin /proxies dizinindeki ProxyEndpoints listesi. Normalde bu öğeyi yalnızca API proxy'si Edge yönetim kullanıcı arayüzü kullanılarak oluşturulduğunda görürsünüz. Bu, API proxy'sinin içeriğine dair görünürlük sağlamak üzere tasarlanmış bir "manifest" ayarıdır. Yok Hayır
Resources Bu API proxy'sinin /resources dizinindeki kaynakların (JavaScript, Python, Java, XSLT) listesi. Normalde bu öğeyi yalnızca API proxy'si Edge yönetim kullanıcı arayüzü kullanılarak oluşturulduğunda görürsünüz. Bu, API proxy'sinin içeriğine dair görünürlük sağlamak üzere tasarlanmış bir "manifest" ayarıdır. Yok Hayır
Spec API proxy'si ile ilişkili OpenAPI Spesifikasyonu'nu tanımlar. Değer, spesifikasyon deposunda bir URL veya yol olarak ayarlanır.

Not: Spesifikasyon deposu yalnızca New Edge deneyiminde kullanılabilir. Spesifikasyon deposu hakkında daha fazla bilgi için Spesifikasyonları yönetme ve paylaşma bölümüne bakın.
Yok Hayır
TargetServers Bu API proxy'sinin herhangi TargetEndpoints'de başvurulan TargetServer'ların listesi. Normalde bu öğeyi yalnızca API proxy'si Edge yönetim kullanıcı arayüzü kullanılarak oluşturulduğunda görürsünüz. Bu, API proxy'sinin içeriğine dair görünürlük sağlamak üzere tasarlanmış bir "manifest" ayarıdır. Yok Hayır
TargetEndpoints Bu API proxy'sinin /targets dizinindeki TargetEndpoints listesi. Normalde bu öğeyi yalnızca API proxy'si Edge yönetim kullanıcı arayüzü kullanılarak oluşturulduğunda görürsünüz. Bu, API proxy'sinin içeriğine dair görünürlük sağlamak üzere tasarlanmış bir "manifest" ayarıdır. Yok Hayır

ProxyEndpoint

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

HTTP hizmetini çağıran bir istemciyi gösterir. İstek, HTTP hizmeti tarafından işlenmeden önce proxy uç noktasından ve ardından hedef uç noktasından geçer. Yanıt, istemciye döndürülmeden önce hedef uç noktasından ve ardından proxy uç noktasından geçer.

/apiproxy/proxies/default.xml

ProxyEndpoint yapılandırması, bir API proxy'si için gelen (istemciye yönelik) arayüzü tanımlar. ProxyEndpoint yapılandırması yaparken istemci uygulamaların ("uygulamalar") proxy kullanan API'yi nasıl çağırması gerektiğini tanımlayan bir ağ yapılandırması ayarlamış olursunuz.

Aşağıdaki örnek ProxyEndpoint yapılandırması /apiproxy/proxies altında depolanı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'te gereken yapılandırma öğeleri şunlardır:

ProxyEndpoint Yapılandırma Öğeleri

Ad Açıklama Varsayılan Zorunlu mu?
ProxyEndpoint
name ProxyEndpoint'in adı. (Nadiren) birden fazla ProxyEndpoint tanımlandığında API proxy yapılandırmasında benzersiz olmalıdır. Adda kullanmanıza izin verilen karakterler şu şekilde sınırlıdır: A-Za-z0-9._\-$ %. Yok Evet
PreFlow Bir istek veya yanıtın PreFlow akışındaki politikaları tanımlar. Yok Evet
Flows
Bir istek veya yanıtın koşullu akışlarındaki politikaları tanımlar.
Yok Evet
PostFlow
Bir istek veya yanıtın PostFlow akışındaki politikaları tanımlar.
Yok Evet
HTTPProxyConnection API proxy'siyle ilişkili ağ adresini ve URI yolunu tanımlar
BasePath

Apigee Edge'in gelen mesajları uygun API proxy'sine yönlendirmek için kullandığı URI yolunu benzersiz şekilde tanımlayan gerekli bir dize.

BasePath, API proxy'sinin (örneğin http://apifactory-test.apigee.net) temel URL'sine eklenen bir URI parçasıdır (örneğin /weather). BasePath bir ortam içinde benzersiz olmalıdır. Benzersizlik, bir API proxy'si oluşturulduğunda veya içe aktarıldığında doğrulanır.

Temel yollarda joker karakter kullanma

API proxy temel yollarında bir veya daha fazla "*" joker karakteri kullanabilirsiniz. Örneğin, /team/*/members temel yolu, yeni ekipleri desteklemek için yeni API proxy'leri oluşturmanıza gerek kalmadan istemcilerin https://[host]/team/blue/members ve https://[host]/team/green/members çağrılarını yapmalarına olanak tanır. /**/ ifadesinin desteklenmediğini unutmayın.

Önemli: Apigee, temel yolun ilk öğesi olarak "*" joker karakterini kullanmayı DESTEKLEMEZ. Örneğin, şu DESTEKLENMEZ: /*/search. Temel yolun "*" ile başlatılması, Edge'in geçerli yolları tanımlama şekli nedeniyle beklenmeyen hatalara yol açabilir.

/ Evet
VirtualHost

Bir API proxy'sini bir ortam için belirli temel URL'lerle ilişkilendirir. VirtualHost, ortam için bir veya daha fazla URL tanımlayan adlandırılmış bir yapılandırmadır.

ProxyEndpoint için tanımlanan adlandırılmış VirtualHost'lar, bir API proxy'sinin açık olduğu alan adlarını ve bağlantı noktalarını ve dolayısıyla uygulamaların API proxy'sini çağırmak için kullandığı URL'yi belirler.

Varsayılan olarak, bir ortam için iki adlandırılmış VirtualHost tanımlanır: default ve secure. Kuruluşlar özel alanlar da tanımlayabilir. Örneğin, bir API proxy'sinin yalnızca HTTPS üzerinden kullanılabilmesi için HTTPProxyConnection'daki VirtualHost'u secure değerine ayarlayın.

varsayılan Hayır
Properties İsteğe bağlı bir dizi HTTP yapılandırma ayarı, <ProxyEndpoint> özellikleri olarak tanımlanabilir. Yok Hayır
FaultRules
ProxyEndpoint'in bir hataya nasıl tepki vereceğini tanımlar. Hata kuralı iki öğe belirtir:
  • Önceden tanımlanmış kategori, alt kategori veya hata adına göre işlenecek hatayı belirten koşul
  • İlgili Koşul için hata kuralının davranışını tanımlayan bir veya daha fazla politika

Hataları yönetme bölümüne bakın.

Yok Hayır
DefaultFaultRule

Başka bir hata kuralı tarafından açıkça işlenmeyen hataları (sistem, aktarım, mesajlaşma veya politika) işler.

Hataları yönetme bölümüne bakın.

Yok Hayır
RouteRule ProxyEndpoint istek ardışık düzeni tarafından işlendikten sonra gelen istek mesajlarının hedefini tanımlar. RouteRule, genellikle adlandırılmış bir TargetEndpoint yapılandırmasına işaret eder ancak doğrudan bir URL'ye de işaret edebilir.
Name RouteRule için bir ad sağlayan gerekli özellik. Bu adda kullanmanıza izin verilen karakterler şu şekilde sınırlıdır: A-Za-z0-9._\-$ %. Örneğin, Cat2 %_ yasal bir addır. Yok Evet
Condition Çalışma zamanında dinamik yönlendirme için kullanılan isteğe bağlı bir koşullu ifade. Koşullu RouteRules, arka uç sürümü oluşturmayı desteklemek için içerik tabanlı yönlendirmeyi etkinleştirmek gibi durumlarda kullanışlıdır. Yok Hayır
TargetEndpoint

Adlandırılmış bir TargetEndpoint yapılandırmasını tanımlayan isteğe bağlı bir dize. TargetEndpoint, /targets dizini altındaki aynı API proxy'sinde tanımlanan herhangi bir TargetEndpoint'tir.

TargetEndpoint adını vererek istek mesajlarının ProxyEndpoint istek ardışık düzeni tarafından işlendikten sonra nereye yönlendirilmesi gerektiğini belirtirsiniz. Bunun isteğe bağlı bir ayar olduğunu unutmayın.

Bir ProxyEndpoint bir URL'yi doğrudan çağırabilir. Örneğin, HTTP istemcisi rolünde çalışan bir JavaScript veya Java kaynağı, istekleri arka uç hizmetine yönlendirmek olan TargetEndpoint'in temel görevini yerine getirebilir.

Yok Hayır
URL ProxyEndpoint tarafından çağrılan giden ağ adresini tanımlayan ve /targets altında depolanabilecek tüm TargetEndpoint yapılandırmalarını atlayan isteğe bağlı dize Yok Hayır

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

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

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

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

Doğrudan URL Çağrısı

ProxyEndpoint bir arka uç hizmetini de doğrudan çağırabilir. Doğrudan URL çağrısı, /apiproxy/targets altında adlandırılmış tüm TargetEndpoints yapılandırmasını atlar. Bu nedenle TargetEndpoint isteğe bağlı bir API proxy yapılandırmasıdır ancak pratikte ProxyEndpoint'ten doğrudan çağrı yapılması önerilmez.

Örneğin, aşağıdaki RouteRule http://api.mycompany.com/v2 öğesine 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, adlandırılmış TargetEndpoint yapılandırmalarına, doğrudan URL'lere veya HTTP üstbilgileri, mesaj içeriği, sorgu parametreleri ya da günün saati, yerel ayar vb. bağlamsal bilgiler temelinde bu ikisinin bir kombinasyonuna yönlendirilebilir.

Koşullu Rota Kuralları, 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 önce bir HTTP üst bilgisinin değerini doğrulamak için gelen isteği değerlendirir. routeTo HTTP üst bilgisi TargetEndpoint1 değerine sahipse 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>

Boş Rotalar

İstek mesajının TargetEndpoint'e yönlendirilmesinin gerekmediği senaryoları desteklemek için boş bir RouteRule tanımlanabilir. Bu, ProxyEndpoint gerekli tüm işlemleri gerçekleştirdiğinde (örneğin, harici bir hizmeti çağırmak için JavaScript kullanarak veya API Hizmetleri'nin anahtar/değer deposuna giden bir aramadan veri alarak) faydalı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, request.header.X-DoNothing HTTP üst bilgisi null dışında bir değere sahip olduğunda yürütülecek boş bir Rota yapılandırılmıştır.

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

RouteKurallar'ın zincirye bağlanabileceğini unutmayın. Bu nedenle, koşullu boş Rota genellikle koşullu yönlendirmeyi desteklemek için tasarlanmış RouteRules kümesinin bir bileşeni olur.

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

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

TargetEndpoint

HTTP hizmetini çağıran bir istemciyi gösterir. İstek, HTTP hizmeti tarafından işlenmeden önce proxy uç noktasından ve ardından hedef uç noktasından geçer. Yanıt, istemciye döndürülmeden önce hedef uç noktasından ve ardından proxy uç noktasından geçer.

TargetEndpoint, ProxyEndpoint'in giden eşdeğeridir. TargetEndpoint, arka uç hizmetinin veya API'nin istemcisi gibi çalışarak istek gönderir ve yanıtlar alır.

API proxy'sinde TargetEndpoints bulunamaz. ProxyEndpoints, URL'leri doğrudan çağıracak şekilde yapılandırılabilir. TargetEndpoint'leri olmayan API proxy'leri genellikle doğrudan bir arka uç hizmetini çağıran ya da Java veya JavaScript kullanarak bir hizmeti çağıracak şekilde yapılandırılmış 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.

Aşağıda örnek bir TargetEndpoint yapılandırması 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ırma Öğeleri

Bir TargetEndpoint, aşağıdaki yöntemlerden birini kullanarak bir hedefi çağırabilir:

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

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

Ad Açıklama Varsayılan Zorunlu mu?
TargetEndpoint
name TargetEndpoint'in adı. Bu ad, API proxy yapılandırmasında benzersiz olmalıdır. TargetEndPoint'in adı, ProxyEndpoint RouteRule'da giden işlemlerin işlenmesine yönelik istekleri yönlendirmek için kullanılır. Adda kullanmanıza izin verilen karakterler şu şekilde sınırlıdır: A-Za-z0-9._\-$ %. Yok Evet
PreFlow Bir istek veya yanıtın PreFlow akışındaki politikaları tanımlar. Yok Evet
Flows
Bir istek veya yanıtın koşullu akışlarındaki politikaları tanımlar.
Yok Evet
PostFlow
Bir istek veya yanıtın PostFlow akışındaki politikaları tanımlar.
Yok Evet
HTTPTargetConnection

Alt öğeleriyle HTTP üzerinden arka uç kaynak erişimini belirtir.

HTTPTargetConnection kullanıyorsanız diğer hedef bağlantı türlerini (ScriptTarget veya LocalTargetConnection) yapılandırmayın.

URL TargetEndpoint'in istek mesajlarını yönlendirdiği arka uç hizmetinin ağ adresini tanımlar. Yok Hayır
LoadBalancer

Bir veya daha fazla adlandırılmış TargetServer yapılandırması tanımlar. Adlandırılmış TargetServer yapılandırmaları, 2 veya daha fazla uç nokta yapılandırma bağlantısı tanımlayan yük dengeleme için kullanılabilir.

API proxy yapılandırmalarını, somut arka uç hizmeti uç nokta URL'lerinden ayırmak için TargetServers'ı da kullanabilirsiniz.

Arka uç sunucular arasında yük dengeleme bölümüne bakın.

Yok Hayır
Properties İsteğe bağlı bir dizi HTTP yapılandırma ayarı, <TargetEndpoint> özellikleri olarak tanımlanabilir. Yok Hayır
SSLInfo API proxy'si ile hedef hizmet arasındaki TLS/SSL bağlantısını kontrol etmek için isteğe bağlı olarak bir TargetEndpoint'te TLS/SSL ayarlarını tanımlayın. TLS/SSL TargetEndpoint Configuration (TLS/SSL TargetEndpoint Yapılandırması) başlıklı makaleye bakın. Yok Hayır
LocalTargetConnection Alt öğeleriyle birlikte yük dengeleme ve mesaj işlemcileri gibi ağ özelliklerini atlayarak yerel olarak erişilecek bir kaynağı belirtir.

Hedef kaynağı belirtmek için APIProxy alt öğesini (ProxyEndpoint öğesiyle) veya Path alt öğesini ekleyin.

Daha fazla bilgi için API proxy'lerini birbirine bağlama bölümüne bakın.

LocalTargetConnection kullanıyorsanız diğer hedef bağlantı türlerini (HTTPTargetConnection veya ScriptTarget) yapılandırmayın.

APIProxy İstekler için hedef olarak kullanılacak API proxy'sinin adını belirtir. Hedef proxy, istek gönderen proxy ile aynı kuruluşta ve ortamda olmalıdır. Bu, Path öğesinin kullanılmasına bir alternatiftir. Yok Hayır
ProxyEndpoint Hedef proxy'nin ProxyEndpoint adını belirtmek için APIProxy ile kullanılır. Yok Hayır
Path İstekler için hedef olarak kullanılacak API proxy'sinin uç nokta yolunu belirtir. Hedef proxy, istekleri gönderen proxy ile aynı kuruluşta ve ortamda olmalıdır. Bu, APIProxy'nin kullanılmasına alternatif olarak kullanılır. Yok Hayır
FaultRules
TargetEndpoint'in bir hataya nasıl tepki vereceğini tanımlar. Hata kuralı iki öğe belirtir:
  • Önceden tanımlanmış kategori, alt kategori veya hata adına göre işlenecek hatayı belirten koşul
  • İlgili Koşul için hata kuralının davranışını tanımlayan bir veya daha fazla politika

Hataları yönetme bölümüne bakın.

Yok Hayır
DefaultFaultRule

Başka bir FaultRule tarafından açıkça işlenmeyen hataları (sistem, aktarım, mesajlaşma veya politika) ele alır.

Hataları yönetme bölümüne bakın.

Yok Hayır
ScriptTarget
ResourceURL

Kaynak türünü (düğümü) ve TargetEndpoint işlevini uygulayan ana Node.js komut dosyasının adını tanımlar.

<ResourceURL>node://server.js</ResourceURL>

Komut dosyasının, API proxy'nizin kaynak dosyalarına eklenmesi gerekir. Mevcut bir API proxy'sine Node.js ekleme başlıklı makaleyi inceleyin.

ScriptTarget kullanıyorsanız diğer hedef bağlantı türlerini (HTTPTargetConnection veya LocalTargetConnection) yapılandırmayın.

Yok Evet
EnvironmentVariable

İsteğe bağlı olarak ortam değişkenlerini ana Node.js komut dosyasına iletin.

Node.js modülleri için Edge desteğini anlama başlıklı makaleyi inceleyin.

Yok Hayır
Arguments

İsteğe bağlı olarak, bağımsız değişkenleri ana Node.js komut dosyasına aktarın.

Node.js modülleri için Edge desteğini anlama başlıklı makaleyi inceleyin.

Yok Hayır

TLS/SSL TargetEndpoint Yapılandırması

TargetEndpoints'in genellikle HTTPS bağlantılarını heterojen arka uç altyapısıyla yönetmesi gerekir. Bu nedenle, bazı TLS/SSL yapılandırma ayarları desteklenmektedir.

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

Ad Açıklama Varsayılan Zorunlu mu?
SSLInfo
Enabled Uç nokta için TLS/SSL'nin etkin olup olmadığını belirtir. <URL> HTTPS protokolünü belirtiyorsa true ve <URL> HTTP'yi belirtiyorsa false varsayılan değerdir. <URL> HTTPS'yi belirtiyorsa doğru Hayır
TrustStore Güvenilir sunucu sertifikalarını içeren bir anahtar deposu. Yok Hayır
ClientAuthEnabled Giden istemci kimlik doğrulamasını (2 yönlü TLS/SSL) etkinleştiren bir ayar false Hayır
KeyStore Giden istemci kimlik doğrulaması için kullanılan özel anahtarları içeren bir anahtar deposu Yok Evet (ClientAuthEnabled doğruysa)
KeyAlias Giden istemci kimlik doğrulaması için kullanılan özel anahtarın anahtar takma adı Yok Evet (ClientAuthEnabled doğruysa)
Ciphers

Giden TLS/SSL için desteklenen şifreler. Şifre belirtilmezse JVM için mevcut olan tüm şifrelere izin verilir.

Şifreleri kısıtlamak için desteklenen şifreleri listeleyen aşağıdaki öğeleri ekleyin:

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>
Yok Hayır
Protocols

Giden TLS/SSL için desteklenen protokoller. Herhangi bir protokol belirtilmezse JVM için mevcut olan tüm protokollere izin verilir.

Protokolleri kısıtlamak için, desteklenen protokollerin listelendiği aşağıdaki öğeleri ekleyin:

<Protocols>
 <Protocol>TLSv1.1</Protocol>
 <Protocol>TLSv1.2</Protocol>
</Protocols>
Yok Hayır
CommonName

Belirtilirse hedef sertifikanın ortak adının doğrulandığı bir değerdir. Bu değer yalnızca TargetEndpoint ve TargetServer yapılandırmaları için geçerlidir. VirtualHost yapılandırmaları için geçerli değildir.

Varsayılan olarak, belirtilen değer hedef sertifikanın ortak adıyla tam olarak eşleştirilir. Örneğin, <CommonName> için *.myhost.com değeri kullanıldığında hedef ana makine adı yalnızca, *.myhost.com tam değeri hedef sertifikadaki ortak ad olarak belirtilirse eşleştirilir ve doğrulanır.

İsteğe bağlı olarak Apigee, wildcardMatch özelliğini kullanarak joker karakterlerle eşleşme gerçekleştirebilir.

Örneğin, hedef sertifikada abc.myhost.com olarak belirtilen ortak bir ad, <CommonName> öğesi aşağıdaki gibi belirtilirse eşleştirilir ve doğrulanır:

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

Yok Hayır

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 Uçtan arka uca TLS'yi yapılandırma (Cloud ve Private Cloud) sayfasına göz atın.

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

Esnek çalışma zamanı gereksinimlerini desteklemek için TLS/SSL ayrıntılarını dinamik olarak da ayarlayabilirsiniz. Örneğin, proxy'niz potansiyel olarak farklı iki hedefe (bir test hedefi ve bir üretim hedefi) bağlanırsa API proxy'nizin hangi ortamı çağırdığını programatik olarak algılamasını ve uygun anahtar deposu ve güven deposuna referansları dinamik olarak ayarlamasını sağlayabilirsiniz. Aşağıdaki Apigee Topluluğu makalesinde bu senaryo daha ayrıntılı bir şekilde açıklanmakta ve dağıtılabilir API proxy örnekleri sağlanmaktadır: https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html.

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

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>

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 durumu dikkate almanız gerekir. Private Cloud kurulumunda statik değerler veya akış değişkenleri kullanarak TLS/SSL'yi yapılandırırken Mesaj İşleyicilerini yeniden başlatmanız gerekebilir.

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

Ancak, isteğe bağlı olarak TargetEndpoint'i bunun yerine anahtar deposu veya güven deposuna bir referans kullanacak şekilde yapılandırabilirsiniz. Referans kullanmanın avantajı, Mesaj İşleyicileri yeniden başlatmak zorunda kalmadan TLS/SSL sertifikasını güncellemek için referansı farklı bir anahtar deposuna veya güven deposuna işaret edecek şekilde güncelleyebilmenizdir.

Örneğin, aşağıda anahtar deposuna başvuru kullanan 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

Takma adın aynı ada sahip olduğundan emin olarak referansı daha sonra farklı bir anahtar deposuna işaret edecek şekilde değiştirmek için 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 dengelemeli TargetEndpoint

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

Ayrıntılı talimatlar için Arka uç sunucular arasında yük dengeleme bölümüne bakın.

Politikalar

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

Politika Yapılandırma Öğeleri

Ad Açıklama Varsayılan Zorunlu mu?
Policy
name

Politikanın dahili adı. Adda kullanabileceğiniz karakterler şunlarla sınırlıdır: A-Za-z0-9._\-$ %. Bununla birlikte, Edge yönetim kullanıcı arayüzü, alfanümerik olmayan karakterleri otomatik olarak kaldırmak gibi ek kısıtlamalar uygular.

İsteğe bağlı olarak, politikayı yönetim kullanıcı arayüzü proxy düzenleyicisinde farklı bir doğal dil adıyla etiketlemek için <DisplayName> öğesini kullanın.

Yok Evet
enabled

Politikayı uygulamak için true olarak ayarlayın.

Politikayı "devre dışı bırakmak" için false olarak ayarlayın. Bu politika, bir akışa bağlı kalsa bile zorunlu kılınmaz.

true Hayır
continueOnError

Bir politika başarısız olduğunda hata döndürülmesi için false olarak ayarlayın. Bu, çoğu politika için beklenen davranıştır.

Bir politika başarısız olduktan sonra bile akış yürütülmesinin devam etmesi için true olarak ayarlayın.

false Hayır
async

Not: Bu özellik, politikanın eşzamansız olarak yürütülmesini sağlamaz. Çoğu durumda bu varsayılan değeri false olarak bırakın.

true olarak ayarlandığında, politika yürütme farklı bir iş parçacığına aktarılır ve ana iş parçacığını ek istekleri ele almak için serbest bırakır. Çevrimdışı işleme tamamlandığında, ana iş parçacığı geri gelir ve mesaj akışını işlemeyi bitirir. Bazı durumlarda, eşzamansız modun true olarak ayarlanması API proxy'sinin performansını iyileştirir. Bununla birlikte, eşzamansız modun aşırı kullanımı, çok fazla iş parçacığı değişimi olursa performansı olumsuz etkileyebilir.

API proxy'lerinde eşzamansız davranış kullanmak için JavaScript nesne modeli konusuna bakın.

false Hayır

Politika Eki

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

HTTP hizmetini çağıran bir istemci gösterilir. İstek, politikaları tetikleyen adımları içeren ProxyEndpoint ve TargetEndpoint ile karşılaşır. HTTP hizmeti yanıtı döndürdükten sonra, yanıt TargetEndpoint ve ardından ProxyEndpoing tarafından işlenir ve istemciye döndürülmeden önce bu yanıt sağlanır. İstekte olduğu gibi yanıt, politikalar tarafından adımlar halinde işlenir.

Yukarıda gösterildiği gibi:

Politikalar, Akışların işleme adımları olarak ekte sunulmuştur. Politikanın adı, işleme adımı olarak uygulanacak politikaya referans vermek amacıyla kullanılır. Politika eklerinin biçimi şu şekildedir:

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

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

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

Politika Eki Yapılandırma Öğeleri

Ad Açıklama Varsayılan Zorunlu mu?
Step
Name Bu adım tanımına göre yürütülecek politikanın adı. Yok Evet
Condition Politikanın uygulanıp uygulanmayacağını belirleyen koşullu ifade. Bir politikanın ilişkili bir koşulu varsa politika yalnızca koşullu ifade "doğru" olarak değerlendirilirse yürütülür. Yok Hayır

Akışlar

ProxyEndpoint ve TargetEndpoint, istek ve yanıt mesajı işleme süreci için bir ardışık düzen tanımlar. İşleme ardışık düzeni, istek akışı ve yanıt akışından oluşur. Her istek akışı ve yanıt akışı; bir veya daha fazla isteğe bağlı "koşullu" veya "adlı" akış ve bir PostFlow olmak üzere alt bölümlere ayrılır.

  • PreFlow: Her zaman yürütülür. Tüm 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 ekleyerek istek yapan istemci uygulamasına yanıt döndürüldükten sonra yürütülür. Bu akışa yalnızca MessageLogging politikası ve Google Stackdriver Logging Uzantısı eklenebilir. PostClientFlow, API proxy gecikmesini azaltır ve client.sent.start.timestamp ve client.sent.end.timestamp gibi yanıt istemciye döndürülene kadar hesaplanmayan bilgileri günlük kaydı için kullanılabilir hale getirir.Akış öncelikle yanıt mesajı için 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 videosunu izleyin

Video: PostClientFlow'da Message Logging'i kullanmayla ilgili bu kısa videoyu izleyin.

Mesaj günlük kaydı politikasının ekli olduğu 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ırada yürütür:

İstek Ardışık Düzeni:

  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. Hedef İstek Yayın Sonrası

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 Yayın Sonrası
  4. Proxy Yanıt Ön Akışı
  5. Proxy Yanıtı Koşullu Akışları (İsteğe Bağlı)
  6. Proxy Yanıt Yayın Sonrası
  7. PostClientFlow Yanıtı (İsteğe Bağlı)

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

Koşullu akışlardan farklı olarak PreFlow ve PostFlow öğelerinin sırası önemli değildir. API proxy'si, Uç Nokta yapılandırmasında nerede göründüklerinden bağımsız olarak her birini her zaman ardışık düzendeki uygun noktada yürütür.

Koşullu Akışlar

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

API proxy'si, koşullu akışta belirtilen koşul için test eder. Koşul karşılanırsa koşullu akıştaki işleme adımları API proxy'si 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, aşağıdakileri temel alarak bir API proxy'sinde işleme adımları uygulama becerisi elde edersiniz:

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

Örneğin, aşağıdaki koşullu akış yalnızca istek kaynak yolu /accesstoken olduğunda yürütüleceğini belirtir. /accesstoken yoluna sahip tüm gelen istekler bu akışın ve söz konusu akışa ekli politikaların yürütülmesine neden olur. İstek yolu /accesstoken son ekini içermiyorsa akış yürütülmez (başka bir koşullu akış gerçekleştirilebilir).

<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 Açıklama Varsayılan Zorunlu mu?
Flow ProxyEndpoint veya TargetEndpoint tarafından tanımlanan bir istek ya da yanıt işleme ardışık düzeni
Name Akışın benzersiz adı. Yok Evet
Condition Doğru veya yanlış olarak değerlendirilmek üzere daha fazla değişkeni değerlendiren koşullu ifade. Önceden tanımlanmış PreFlow ve PostFlow türleri dışındaki tüm Akışlar, yürütmeleri için bir koşul tanımlamalıdır. Yok Evet
Request İstek mesajı işlemeyle ilişkili ardışık düzen Yok Hayır
Response Yanıt mesajı işlemeyle ilişkili ardışık düzen Yok Hayır

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 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 son ekini içermeyen tüm gelen istekler, ThirdFlow adlı uygulamanın yürütülmesine neden olarak Return404 adlı politikayı uygular.

<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ım için kaynak dosyaları), politikalar kullanarak 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, bir ortamda veya bir kuruluşta depolanabilir. Her durumda, bir kaynağa Politikada adla referans verilir. API Services, API proxy'sinden ortama veya kuruluş düzeyine geçiş yaparak adı çözer.

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