Ana içeriğe atla
Bu doküman spesifik bir politikanın detaylı kullanımını anlatır. Eğer Apinizer politika yapısını ilk kez kullanıyorsanız veya politikaların genel çalışma prensiplerini öğrenmek istiyorsanız, öncelikle Politika Nedir? sayfasını okumanızı öneririz.

Genel Bakış

Amacı Nedir?

  • Script Politikası, API Proxy (API Vekil Sunucusu) istek hattında özel iş kuralları ve veri dönüşümleri uygulayarak entegrasyon gereksinimlerini kod yazmadan çözmeyi hedefler.
  • Script Politikası, yanıt hattında gelen verileri maskeleme, zenginleştirme veya hata mesajlarını uyarlama gibi işlemleri merkezi olarak yönetmeyi sağlar.
  • Script Politikası, farklı ortamlar arasında tutarlı davranış için global/local paylaşımlı script kütüphanesi oluşturmayı mümkün kılar.
  • Script Politikası, koşul motoru sayesinde yalnızca belirlenen endpoint veya header kombinasyonlarında devreye girerek performansı korur.

Çalışma Prensibi

  1. İstek Gelişi: API Gateway’e gelen her HTTP/HTTPS isteği için, istemin kaynak IP adresi tespit edilir.
  2. Politika Kontrolü: Script Politikası aktif ise, sistem aşağıdaki sırayla kontrol yapar:
    • Condition (koşul) tanımlı mı? Varsa koşul sağlanıyor mu?
    • Politika aktif mi (active=true)?
    • Variable kullanılıyor mu yoksa Apinizer default mı?
  3. Script Motoru Yürütmesi: Seçilen executionType (SYNC/ASYNC) ve scriptLanguage (Groovy/Javascript) değerlerine göre script, belirlenen pipeline bölgesinde çalıştırılır; istek/yanıt body, header ve parametre haritaları güncellenebilir.
  4. Karar Verme:
    • Eşleşme Var: Script sonucunda güncellenen mesaj bileşenleri pipeline’a geri yazılır, hata durumunda tanımlı statusCode ve mesaj döner.
    • Eşleşme Yok: Script atlanır, istek/yanıt varsayılan akışına devam eder.
  5. Hata İşleme: Politika kuralına uymayan istekler için özelleştirilebilir HTTP durum kodu ve hata mesajı döndürülür.

Özellikler ve Yetenekler

Temel Özellikler

  • ExecutionType Yönetimi (Sync/Async): Scriptin eşzamanlı mı yoksa arka planda mı yürütüleceğini belirler; asenkron mod uzun süren işlemlerde uç noktayı bloklamaz.
  • Çift Script Dili Desteği: Groovy ve Javascript arasında seçim yaparak ekiplerin hâkim oldukları dili kullanmalarını sağlar.
  • Bağlam Değişkeni Kütüphanesi: From Client, To Backend, From Backend ve To Client akışları için hazır değişken haritaları sunar; okunabilir/yazılabilir alanlar net olarak ayrılmıştır.
  • Aktif/Pasif Durum Kontrolü: Politikanın aktif veya pasif durumunu kolayca değiştirme (active/passive toggle). Pasif durumda politika uygulanmaz ancak yapılandırması saklanır.
  • Koşul Bazlı Uygulama: Query Builder ile karmaşık koşullar oluşturarak politikanın ne zaman uygulanacağını belirleme (örn: sadece belirli endpoint’lere veya header değerlerine göre).

İleri Düzey Özellikler

  • Script Test Laboratuvarı: Entegre test penceresiyle farklı pipeline segmentleri için örnek header/param/body verileriyle script çalıştırma ve sonucu inceleme.
  • Bağımlılık İzleme: Used Proxies/Policy Groups bölümleriyle politikanın hangi API Proxy veya gruplarda kullanıldığını görüp değişiklik etki analizi yapma.
  • Dinamik Context Value Seçimi: EnumScriptContextValue üzerinden tarih, ortam veya proxy metadata bilgilerini script içerisinde kullanmak için otomatik kopyalama.
  • Export/Import Özelliği: Politika yapılandırmasını ZIP dosyası olarak export etme. Farklı ortamlara (Development, Test, Production) import etme. Versiyon kontrolü ve yedekleme imkanı.
  • Policy Group ve Proxy Group Desteği: Birden fazla politikayı Policy Group içinde yönetme. Proxy Group’lara toplu politika atama. Merkezi güncelleme ve deploy işlemleri.
  • Deploy ve Versiyonlama: Politika değişikliklerini canlı ortama deploy etme. Hangi API Proxy’lerde kullanıldığını görme (Policy Usage). Proxy Group ve Policy Group kullanım raporları.

Kullanım Senaryoları

Politika Parametrelerini Yapılandırma

Bu adımda, kullanıcı yeni bir politika oluşturabilir ya da mevcut politika parametrelerini yapılandırarak erişim kurallarını belirleyebilir.

Yeni Script Politikası Oluşturma

Script Politikası

Yapılandırma Adımları

Adım 1: Oluşturma Sayfasına Gitme

Sol menüden Development → Global Settings → Global Policies → Script Politikası bölümüne gidin ve sağ üstteki [+ Create] butonuna tıklayın.

Adım 2: Temel Bilgileri Girme

Policy Status (Politika Durumu): Aktif/Pasif durumu gösterir. Yeni politikalar varsayılan olarak aktiftir. Name (İsim) - Zorunlu: Benzersiz isim girin (örnek: Production_ScriptPolicy). Sistem otomatik kontrol eder. Yeşil tik: kullanılabilir, Kırmızı çarpı: mevcut isim. Description (Açıklama): Politikanın amacını açıklayın (Maks. 1000 karakter). Örnek: “İstek hattında kampanya header’ı ekler.”

Adım 3: Variable Kullanımı

  • Sayfanın üst kısmındaki işlem butonları alanında, [<> Variable] butonunu kullanarak dinamik değer seçebilirsiniz.
  • Context/global variable ifadeleri sayesinde politika parametrelerini sabit değer yerine değişken tabanlı yönetebilirsiniz.
  • Bu kullanım, değişen değerlerde manuel güncelleme ihtiyacını azaltır ve operasyonel kolaylık sağlar.
  • Detaylı bilgi için Dinamik Değişkenler sayfasını inceleyebilirsiniz.

Adım 4: ExecutionType Seçimi

Execution Type bölümünde Sync veya Async seçin:
  • Sync seçildiğinde script gateway pipeline’ında eşzamanlı yürür
  • Async, uzun süren operasyonlarda istemciyi bekletmemek için uygun olup yan kanal tetikler

Adım 5: Script Dili Yapılandırması

Script Language altında Javascript veya Groovy seçin. Seçim kod editörünün sözdizimini ve IntelliSense’i belirler.

Adım 6: Script Gövdesi ve Değişken Yönetimi

  • Kod editörüne scriptinizi yazın veya yapıştırın
  • Değişken etiketlerinden requestHeaderMapToTargetAPI, responseBodyTextToClient gibi alanları bir tıklamayla panoya kopyalayın
  • customVariableMap üzerinden diğer politikalara veri aktarabilirsiniz
  • Try It butonu ile test diyaloğunu açıp örnek girişlerle scripti çalıştırın

Adım 7: Koşul Tanımlama (İsteğe Bağlı)

Condition sekmesine geçin. Koşullar, politikanın hangi durumda aktif olacağını belirler. Örnekler:
  • Ortam bazlı: Header = X-Environment, Operator = Equals, Value = production
  • API Key bazlı: Header = X-API-Key, Starts With = PROD-
  • Endpoint bazlı: Path = /api/admin/*
Koşul tanımlamazsa politika her zaman aktif olur. Detaylar için bakabilirsiniz: Koşullar (Conditions)

Adım 8: Hata Mesajı Özelleştirme (İsteğe Bağlı)

Error Message Customization sekmesine gidin ve erişim reddedildiğinde dönecek mesajı özelleştirin. Varsayılan:
Özel:

Adım 9: Kaydetme

Sağ üstteki [Save] butonuna tıklayın. Kontrol Listesi:
  • Benzersiz isim
  • Zorunlu alanlar dolu
  • En az bir script gövdesi satırı mevcut
Sonuç:
  • Politika listeye eklenir
  • API’lere bağlanabilir
  • Global politikaysa otomatik uygulanır
Koşullar ve Hata Mesajı Özelleştirme panellerinin açıklaması için Politika Nedir? sayfasındaki Koşullar ve Hata Mesajı Özelleştirme (Error Message Customization) bölümlerini inceleyebilirsiniz. Hata mesajı yapılandırmasının tüm katmanları, öncelik sırası ve senaryo örnekleri için Hata Mesajı Yapılandırma Rehberi sayfasına bakın.

Flow Variables (Akış Değişkenleri)

Script Politikası içerisinde kullanabileceğiniz akış değişkenleri ve özellikleri aşağıdaki tablolarda detaylı olarak açıklanmıştır.

İstek Değişkenleri (Client → Apinizer)

İstek Değişkenleri (Apinizer → Backend API)

Yanıt Değişkenleri (Backend API → Apinizer)

Yanıt Değişkenleri (Apinizer → Client)

Detaylı Kullanım Örnekleri

Form URL-Encoded Kullanımı

Form Data Kullanımı

Backend URL Değiştirme

Örnek Senaryo: Mevcut routing adresi: “https://apinizer.com/api” olsun, Gelen istek kapsam yolu: “/findByStatus?param=value” olsun. Bu durumda istek şu adrese gider: “https://apinizer.com/api/findByStatus?param=value Aşağıdaki kod yazıldığında:
İstek şu adrese gider: “https://apinizer.com/api/new/path/value?p=v Aşağıdaki kod yazıldığında:
İstek şu adrese gider: “https://apinizer.com/api

Önemli Notlar

Script tipi Groovy ise:
  • Mesaj gövdesi JSON olan durumda JsonSlurper,
  • Mesaj gövdesi XML olan durumda XMLSlurper
kullanılması, mesaj işleme işlemini oldukça kolaylaştırır.
Hata mesajı değişkenleri ile istek bloke olduğunda istemciye, hata mesajı olarak Hata Yanıt Şablonu (Error Message Template) yerine bu değişkenin değerine ne yazıldıysa o dönmektedir.

Message Variables (Mesaj Değişkenleri)

Script Politikası içerisinde kullanabileceğiniz mesaj değişkenleri ve özellikleri aşağıdaki tablolarda detaylı olarak açıklanmıştır.

İstek Hattı Değişkenleri

Yanıt Hattı Değişkenleri

Kodlama Değişkenlerinin Davranışı ve Yönlendirme Ayarları

Script politikasında istek veya yanıt hattındaki veri formatı (gzip, deflate, br, zstd, compress, identity) değişkenleri yazılabilir. Bu değişkenler, yönlendirme ayarlarındaki veri formatı geçersizlik (encoding override) ayarları ile birlikte çalışır ve aralarındaki öncelik sırası önemlidir.

Çalışma Sırası

Bir isteğin veri akışı aşağıdaki adımlardan geçer:
  1. İstemciden gelen başlıklar okunur — İstemcinin gönderdiği veri formatı başlığı değerlendirilir.
  2. Yönlendirme geçersizlik ayarları uygulanır — API Proxy veya Yönlendirme tanımındaki veri formatı geçersizlik değerleri, istemciden gelen başlığı ezer.
  3. Gövde açılır — Ayarlara göre sıkıştırılmış istek gövdesi açılır.
  4. Backend yönünde sıkıştırma geçersizliği uygulanır — Backend’e gönderilirken kullanılacak format belirlenir.
  5. İstek hattı politikaları çalışır — Script politikası bu aşamada devreye girer. Script içinde veri formatı değişkeni yazılırsa önceki tüm ayarları ezer.
  6. Gövde backend’e gönderilir — Script’in bıraktığı son değere göre sıkıştırma uygulanır.
Yanıt hattı da aynı mantıkla çalışır; backend’ten gelen yanıt için yönlendirme ayarları önce uygulanır, yanıt hattı script politikası en son söz sahibidir.
Script içinde veri formatı değişkeni yazıldığında, yönlendirme ayarlarında tanımlanan geçersizlik değerleri sessizce ezilir. Script politikası ile yönlendirme ayarları aynı API Proxy’de birlikte kullanılıyorsa, hangi değerin öncelikli olacağı bilinçli planlanmalıdır.

Tek Seferde Tek Format

Bir istek veya yanıt için aynı anda yalnızca tek bir veri formatı aktif olmalıdır. Script içinde bir formatı true yapıyorsanız, diğer tüm format değişkenlerini açıkça false olarak ayarlamak gerekir. Aksi halde birden fazla format aynı anda aktif kalabilir ve backend ya da istemci tarafında beklenmeyen sonuçlar oluşur. Önerilen kullanım:

Başlık Tutarlılığı

Veri formatı değişkeni değiştirildiğinde, istek veya yanıt başlıklarındaki Content-Encoding değeri de aynı değere getirilmelidir. Format değişkeni ile başlık değeri arasında uyuşmazlık olması, istemcinin veya backend’in gövdeyi açmakta sorun yaşamasına neden olur.

Ne Zaman Script, Ne Zaman Yönlendirme Ayarı

  • Yönlendirme ayarı (geçersizlik): Tüm istekler için sabit bir kural uygulanacaksa (örn. her istek mutlaka gzip olarak backend’e gitsin). Daha güvenli ve hataya açık olmayan seçenektir.
  • Script: Karar çalışma zamanında dinamik olarak alınacaksa (örn. istemcinin IP adresine veya başlık değerine göre farklı format kullanılsın). Script içinde tüm format değişkenleri ve ilgili başlıklar birlikte yönetilmelidir.
İki yöntem aynı anda kullanılıyorsa script son söz sahibidir.

Mesaj Değişkenleri

Ortam Değişkenleri

Credential Değişkenleri

Custom Variables (Özel Değişkenler)

Request veya Response pipeline üzerindeki politikalar ile geçici olarak değişken tanımlama ve sonraki politikada kullanma ihtiyacı olabilir. Bu durumda customVariableMap değişkeni kullanılabilir.

Önemli Kısıtlamalar

Pipeline Kısıtlamaları:
  • İstek Hattına eklenen Script Politikası Yanıt Hattındaki değişkenlere erişemez.
  • Yanıt Hattına eklenen Script Politikası ise İstek Hattındaki değişkenleri sadece okuyabilir.

Politikayı Silme

Bu politikanın silme adımları ve kullanımdayken uygulanacak işlemler için Politika Yönetimi sayfasındaki Akıştan Politika Kaldırma bölümüne bakabilirsiniz.

Politikayı Dışa/İçe Aktarma

Bu politikanın dışa aktarma (Export) ve içe aktarma (Import) adımları için Export/Import sayfasına bakabilirsiniz.

Politikayı API’ye Bağlama

Bu politikanın API’lere nasıl bağlanacağına ilişkin süreç için Politika Yönetimi sayfasındaki Politikayı API’ye Bağlama bölümüne bakabilirsiniz.

İleri Düzey Özellikler

Best Practices

Yapılması Gerekenler ve En İyi Uygulamalar

Güvenlik En İyi Uygulamaları

Kaçınılması Gerekenler

Performans İpuçları

Sık Sorulan Sorular (SSS)