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:
- Edge kullanıcı arayüzündeki XML düzenleyiciyi kullanma
- Yapılandırmayı indirin ve Proxy yapılandırmalarının yerel olarak geliştirilmesi bölümünde açıklandığı gibi yerel olarak düzenleyin.
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:
- 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.)
- 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.
- 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 dosyadefault.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.
- Proxy yapılandırma dosyalarını düzenlemeyi tamamladığınızda değişikliklerinizi kaydettiğinizden emin olun.
- 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. - 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.
- 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.
- 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:
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:
/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 Temel yollarda joker karakter kullanma API proxy temel yollarında bir veya daha fazla "*" joker karakteri kullanabilirsiniz. Örneğin, Önemli: Apigee, temel yolun ilk öğesi olarak "*" joker karakterini kullanmayı DESTEKLEMEZ. Örneğin, şu DESTEKLENMEZ: |
/ | 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: |
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:
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, 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
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:
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.
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 İsteğe bağlı olarak Apigee, Örneğin, hedef sertifikada <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: İ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 |
Yok | Evet |
enabled |
Politikayı uygulamak için Politikayı "devre dışı bırakmak" için |
true | Hayır |
continueOnError |
Bir politika başarısız olduğunda hata döndürülmesi için Bir politika başarısız olduktan sonra bile akış yürütülmesinin devam etmesi için |
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
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:
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:
- Proxy İsteği Ön Akışı
- Proxy İsteği Koşullu Akışları (İsteğe Bağlı)
- Proxy İstek Sonrası Akış
- Hedef İstek Ön Akışı
- Hedef İstek Koşullu Akışları (İsteğe Bağlı)
- Hedef İstek Yayın Sonrası
Yanıt Ardışık Düzeni:
- Hedef Yanıt Ön Akışı
- Hedef Yanıt Koşullu Akışları (İsteğe Bağlı)
- Hedef Yanıt Yayın Sonrası
- Proxy Yanıt Ön Akışı
- Proxy Yanıtı Koşullu Akışları (İsteğe Bağlı)
- Proxy Yanıt Yayın Sonrası
- 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.