Koşullu Politika Çalıştırma

​

Koşullu Politika Çalıştırma Kavramı

Koşullu politika çalıştırma, politikaların belirli koşullara göre çalıştırılmasını sağlar. Apinizer’da koşullar kod yazmadan, Variable kullanarak ve form tabanlı yapılandırma ile oluşturulur. Aşağıdaki diyagram, koşullu politika çalıştırmanın Gateway üzerinden nasıl gerçekleştiğini gösterir:

​

Form Tabanlı Koşul Oluşturma

Koşullu politika oluştururken aşağıdaki adımlar izlenir: Bu yaklaşım sayesinde kod yazmadan, form alanlarını doldurarak ve Variable’ları seçerek koşullu politikalar oluşturabilirsiniz.

​

Koşul Türleri ve Değişken Kullanımı

Koşullar, Variable kullanılarak oluşturulur. Değişkenler mesaj içeriğinden, header’lardan, query parametrelerinden veya context’ten değer alabilir.

​

Mesaj İçeriği Koşulları

Mesaj içeriğine göre koşullar oluşturmak için JSONPath veya XPath kullanarak değişken tanımlanır:

​

İstemci Koşulları

İstemci bilgilerine göre koşullar oluşturmak için ilgili değişkenler kullanılır:

​

Zaman Koşulları

Zaman bazlı koşullar için sistem değişkenleri kullanılır:

​

Sistem ve Ortam Koşulları

Sistem ve ortam değişkenlerine göre koşullar:

​

Koşul Yapılandırması

Koşullar, Variable kullanılarak ve form tabanlı yapılandırma ile oluşturulur. Her koşul aşağıdaki bileşenlerden oluşur:

​

Koşul Bileşenleri

1. İlk Değişken (First Variable): Karşılaştırmanın sol tarafındaki değişken
   • Header değişkeni
   • Query parametre değişkeni
   • Mesaj içeriği değişkeni (JSONPath/XPath)
   • Context değişkeni
   • Özel değişken
2. Veri Tipi (Variable Data Type): Değişkenin veri tipi
   • STRING: Metin karşılaştırmaları için
   • NUMERIC: Sayısal karşılaştırmalar için
   • DATE: Tarih karşılaştırmaları için (tarih formatı belirtilmelidir)
3. Karşılaştırma Operatörü (Comparison Operator): İki değer arasındaki karşılaştırma türü
4. İkinci Değer Kaynağı (Second Value Source):
   • Sabit Değer: Doğrudan girilen sabit bir değer
   • Değişken: Başka bir değişken seçimi
5. Mantıksal Operatör (Condition Criteria): Birden fazla koşulu birleştirmek için
   • AND: Tüm koşulların sağlanması gerekir
   • OR: Koşullardan en az birinin sağlanması gerekir
   • NOT: Koşulun sağlanmaması gerekir

​

Karşılaştırma Operatörleri

Koşullarda kullanılabilecek karşılaştırma operatörleri:

​

Metin (STRING) Operatörleri

​

Sayısal (NUMERIC) Operatörleri

​

Tarih (DATE) Operatörleri

Tarih karşılaştırmaları için tarih formatı belirtilmelidir (örn: yyyy-MM-dd, dd/MM/yyyy).

​

Varlık Kontrolü Operatörleri

Bu operatörler ikinci değer gerektirmez, sadece değişkenin durumunu kontrol eder:

​

Null Değer İşleme

Koşullarda null değerler özel şekilde işlenir:

​

Koşul Oluşturma Örnekleri

Aşağıdaki örneklerde, form tabanlı yaklaşımla koşulların nasıl oluşturulduğu gösterilmektedir:

​

Örnek 1: Content-Type Bazlı Validation

Senaryo: Content-Type header’ına göre farklı validation politikaları uygulanacak. Form Yapılandırması:

• İlk Değişken: Header değişkeni seçilir → Content-Type
• Veri Tipi: STRING
• Operatör: Eşittir (EQ)
• İkinci Değer Kaynağı: Sabit değer
• İkinci Değer: application/json

Sonuç: Content-Type header’ı application/json ise JSON Schema Validation Policy çalışır. Alternatif Koşullar (nested koşullar):

• Koşul 1: Content-Type application/xml ise → XML Schema Validation Policy
  • İlk Değişken: Header → Content-Type
  • Operatör: EQ
  • İkinci Değer: application/xml
• Koşul 2: Diğer durumlar → Reject Request (400 Bad Request)
  • ELSE durumu

​

Örnek 2: API Version Bazlı Routing

Senaryo: Query parametresindeki version değerine göre farklı backend’lere yönlendirme yapılacak. Form Yapılandırması:

• İlk Değişken: Query Parameter değişkeni seçilir → version
• Veri Tipi: STRING
• Operatör: Eşittir (EQ)
• İkinci Değer Kaynağı: Sabit değer
• İkinci Değer: v1

Sonuç: Query parametresi version=v1 ise Backend v1’e route edilir. Alternatif Koşullar:

• Koşul 1: Version v2 ise → Backend v2’ye route
  • İlk Değişken: Query Parameter → version
  • Operatör: EQ
  • İkinci Değer: v2
• Koşul 2: Diğer durumlar → Default Backend’e route
  • ELSE durumu

​

Örnek 3: User Role Bazlı Authorization

Senaryo: Kullanıcı rolüne göre farklı politika uygulanacak. Form Yapılandırması:

• İlk Değişken: Context Variable seçilir → context.user.role
• Veri Tipi: STRING
• Operatör: Eşittir (EQ)
• İkinci Değer Kaynağı: Sabit değer
• İkinci Değer: admin

Sonuç: Kullanıcı rolü admin ise tüm işlemlere izin verilir. Alternatif Koşullar:

• Koşul 1: Role user ise → Rate Limiting Policy (100 req/min)
  • İlk Değişken: Context Variable → context.user.role
  • Operatör: EQ
  • İkinci Değer: user
• Koşul 2: Diğer durumlar → Reject Request (403 Forbidden)
  • ELSE durumu

​

Örnek 4: IP Bazlı Rate Limiting

Senaryo: IP adresine göre farklı rate limit değerleri uygulanacak. Form Yapılandırması:

• İlk Değişken: Client IP değişkeni seçilir
• Veri Tipi: STRING
• Operatör: İçinde (IN)
• İkinci Değer Kaynağı: Sabit değer
• İkinci Değer: 192.168.1.0/24#10.0.0.0/8 (liste değerleri # ile ayrılır)

Sonuç: IP adresi belirtilen aralıklardan birinde ise Rate Limiting Policy (1000 req/min) uygulanır. Alternatif Koşul:

• Koşul 2: Diğer durumlar → Rate Limiting Policy (100 req/min)
  • ELSE durumu

​

Örnek 5: Time-based Access Control (Nested Koşullar)

Senaryo: Çalışma saatleri içinde erişim izni verilecek. Form Yapılandırması (Nested koşullarla AND mantığı):

• Mantıksal Operatör: AND seçilir
• İlk Alt Koşul:
  • İlk Değişken: System Variable → current.time
  • Veri Tipi: STRING veya DATE (saat formatına göre)
  • Operatör: Büyük Eşittir (GE)
  • İkinci Değer: 09:00
• İkinci Alt Koşul:
  • İlk Değişken: System Variable → current.time
  • Veri Tipi: STRING veya DATE
  • Operatör: Küçük Eşittir (LE)
  • İkinci Değer: 17:00

Sonuç: Saat 09:00-17:00 arası ise istek kabul edilir, aksi halde reddedilir (503 Service Unavailable).

​

Nested Koşullar (Koşul Kombinasyonları)

Karmaşık mantık için nested koşullar oluşturabilirsiniz. Form tabanlı yaklaşımda alt koşullar ekleyerek koşulları birleştirirsiniz:

​

AND Operatörü

Form Yapılandırması:

• Mantıksal Operatör: AND seçilir
• İlk Alt Koşul:
  • İlk Değişken: Header → Content-Type
  • Veri Tipi: STRING
  • Operatör: Eşittir (EQ)
  • İkinci Değer: application/json
• İkinci Alt Koşul:
  • İlk Değişken: Header → X-API-Key
  • Veri Tipi: STRING
  • Operatör: Eşittir (EQ)
  • İkinci Değer: premium-key

Sonuç: Her iki koşul da sağlanırsa Premium JSON Processing Policy çalışır.

​

OR Operatörü

Form Yapılandırması:

• Mantıksal Operatör: OR seçilir
• İlk Alt Koşul:
  • İlk Değişken: Client IP
  • Veri Tipi: STRING
  • Operatör: İçinde (IN)
  • İkinci Değer: 192.168.1.0/24#10.0.0.0/8
• İkinci Alt Koşul:
  • İlk Değişken: Header → X-API-Key
  • Veri Tipi: STRING
  • Operatör: Eşittir (EQ)
  • İkinci Değer: internal-key

Sonuç: Koşullardan biri sağlanırsa Internal Access Policy çalışır.

​

NOT Operatörü

Form Yapılandırması:

• Mantıksal Operatör: NOT seçilir
• Alt Koşul:
  • İlk Değişken: Client IP
  • Veri Tipi: STRING
  • Operatör: İçinde (IN)
  • İkinci Değer: 10.0.0.0/8

Sonuç: IP belirtilen aralıkta değilse External Access Rate Limiting uygulanır.

​

Değişken Karşılaştırması

Koşullarda sadece sabit değerlerle değil, değişkenler arası karşılaştırma da yapabilirsiniz: Form Yapılandırması:

• İlk Değişken: Header → Content-Type
• Veri Tipi: STRING
• Operatör: Eşittir (EQ)
• İkinci Değer Kaynağı: Değişken seçilir
• İkinci Değişken: Context Variable → context.preferred.contentType

Sonuç: İki değişken birbirine eşitse politika çalışır. Bu yaklaşım dinamik karşılaştırmalar için kullanılır.

​

Koşullu Politika Best Practices

​

Sonraki Adımlar