Azure API Management Policy Kullanımı

0 dakikada yazıldı

21274 defa okundu

Düzenle

Bir önceki
yazıda
Azure API Management konusuna hızlı bir giriş yapmıştık. Basit bir
servisi alıp wrap etmiştik. Bu yazıda biraz daha derinlere girip sadece
UrlReWrite değil farklı transformasyonlara da göz atacağız. Bunun için
API Management portalındaki Policies sekmesine yönelmemiz gerekiyor.

Policy'ler ile bir çok farklı hareket yapmak mümkün.
Policy'ler ile bir çok farklı hareket yapmak mümkün.

Policies ekranına geçtiğinde portalınızdaki bir ürün, API ve sonrasında
da API'ın operasyonunu seçmeniz gerekiyor. Bir önceki makalede
hazırladığımız HavaDurumu servisinden ilerleyecek olursak bizim zaten
bir GET operasyonumuz vardı. Hatırlarsanız kullandığımız harici servis
XML çıktı veriyordu. Gelin biz bu XML'i bizim API'larımızdan
gerektiğinde JSON olarak verilebilecek hale getirelim. Bunun için
"Configure Policy" düğmesine tıklayarak sağ tarafta bulunan olası policy
askyonlarından "Convert XML to JSON"ı alıp orta kısma sürüklemeniz
gerekiyor. Burada editör çok da süper bir editör değil açıkçası :) O
nedenle XML dokümanı içerisinde doğru şeyleri doğru yerlere koymazsanız
hata alırsınız.

<policies>
    <inbound>
        <base />
        <rewrite-uri template="forecast?q={sehir}&amp;mode=xml" />
    </inbound>
    <outbound>
        <xml-to-json kind="direct" apply="content-type-xml" consider-accept-header="true" />
        <base />
    </outbound>
</policies>

Kullanacağımız final policy dosyası yukarıdaki gibi olacak. Outbound
tagının içerisinde çıkışta XML-JSON çeviri işlemi yapacağımızı
ekliyoruz. Bu işlemi yaparken de API'mıza gelen talepteki Accept
Header'ına saygı duyacağımızı belirtmemizde fayda var. Aksi halde
sürekli JSON vermek durumunda kalabiliriz. Bence isteyenin kendi
istediği çıktıyı seçebilmesi önemli.

JSON Output hazır.
JSON Output hazır.

Artık dışarıdan API'mız çağrıldığında eğer Accept Header'da app/json
varsa API'mız kendisine gelen XML'i JSON'a çevirerek dışarıya verecek.
Böylece aslında bakarsanız olası bir senaryoda şirket içerisindeki bir
XML çıktıya sahip servisi alıp güzel bir JSON API'ına UrlRewrite ile
REST API konseptine uygun bir şekilde toparlayarak işimizi hızlıca
bitirebiliyoruz. Gelin bir adım daha ileri giderek bir de output cache
ekleyelim API'mıza. Sürekli içerideki diğer servise gitmek
istemeyebiliriz.

<policies>
    <inbound>
        <cache-lookup vary-by-developer="true" vary-by-developer-groups="false" downstream-caching-type="public">
            <vary-by-header>Accept</vary-by-header>
            <vary-by-header>Accept-Charset</vary-by-header>
        </cache-lookup>
        <base />
        <rewrite-uri template="forecast?q={sehir}&amp;mode=xml" />
    </inbound>
    <outbound>
        <xml-to-json kind="direct" apply="content-type-xml" consider-accept-header="true" />
        <base />
        <cache-store duration="90" caching-mode="cache-on" />
    </outbound>
</policies>

Bu sefer policymizin iki farklı ayağına da dokunmamız gerekiyor. InBound
ayağında eğer varsa önbelleklenmiş bir şey onu dışarıya aktarmamız
gerek. O nedenle InBound'da Cache-Lookup yapıyoruz. Lookup yaparken
cache'in neye göre invalide olacağına karar verebilirsiniz. Benim
örneğimde ilk olarak her developer için ayrı önbelleklenme şartı koştum
fakat developer grouplarına göre ise önbelleği ayırmadım. Developer
Group konsepti Azure Management API'ın Management ekranında var olan bir
gruplama yapısı. Son olarak Accept Header'ının ve Charset'in de ayrı
ayrı önbelleklenmesi şart :) JSON isteyene XML vermek istemiyorsanız :)

Önbellek ayarlarını yaptıktan sonra sıra geliyor çıkış noktasında
önbellek çıktısını açıp önbellek süresini belirlemeye. Bizim örneğimizde
önbellek süresi 90 saniye.

Önbellekleme 90 saniyede.
Önbellekleme 90 saniyede.

Yukarıdakiler gibi bir çok policy aksyonu mevcut. Bunların içerisinde
full text replace bile var :) Açıkçası XSLT tadında bir şema
transformasyon aracı olsaydı tadından yenmezdi :) ve belki de şu an
bulunan çoğu policy aksyonunu daha generic bir seçenekle sağlamış
olabilirlerdi. Fakat öyle bir şey yok :) Nitekim API Management'a aşırı
yük yüklemek de çok doğru olmayabilir. Özellikle önbelleklemeyi
açmazsanız ve çok fazla response processing yaparsanız yavaşlıklarla baş
başa kalabilirsiniz veya sırf bu nedenle scale etmek zorunda da
kalabilirsiniz. O nedenle belki de en önemli noktalardan biri doğru
önbellekleme politikasını tanımlamış olmak. Tabi önbelleğinizi toplam
miktarı da bir noktaca scale etmenize neden olabilir :) Tabi günün
sonunda bu servisleri sattığınızı düşünürsek pek de büyük dert olmasa
gerek.

Görüşmek üzere.