Genel Bakış
API Call politikası, API Gateway üzerinden başka REST API’leri çağırarak mikroservis mimarisinde servis-servis iletişimi kurar. Gelen istekleri backend sistemlere yönlendirir, yanıtları işler ve API Proxy akışına entegre eder. Bu sayede harici servislerden veri çekmek, istekleri zenginleştirmek veya birden fazla kaynaktan gelen yanıtları birleştirmek mümkün olur.Amacı Nedir?
- API Gateway üzerinden geçen istekleri başka bir REST API’ye yönlendirerek mikroservis mimarilerinde servis-servis iletişimini sağlamak.
- Gelen istekleri zenginleştirmek, dönüştürmek ve birden fazla backend servisinden veri toplayarak birleştirilmiş yanıtlar oluşturmak (API Orchestration).
- Harici sistemlerden (CRM, ERP, ödeme gateway’leri vb.) veri çekmek veya veri göndermek için güvenli ve yönetilebilir bir köprü oluşturmak.
- Request ve Response mesajları üzerinde header, parameter ve body manipülasyonu yaparak veri dönüşümü gerçekleştirmek.
- Cache mekanizması ile sık kullanılan API çağrılarının sonuçlarını önbelleğe alarak performansı artırmak ve backend sistemlere olan yükü azaltmak.
Çalışma Prensibi
- İstek Gelişi: API Gateway’e gelen her HTTP/HTTPS isteği için, REST API Call politikası aktif ise çağrı işlemi başlatılır.
- Politika Kontrolü: 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ı?
- Request Hazırlama (Before Call): İstek gönderilmeden önce:
- Body temizlenir veya yeni içerik eklenir
- Header ve parametreler manipüle edilir (ekleme/silme)
- Data Manipulation kuralları uygulanır
- Cache kontrolü yapılır (varsa önbellekten döner)
- API Çağrısı: Tanımlanan URL’ye HTTP method ile istek gönderilir:
- Synchronous (Senkron): Yanıt beklenir ve işleme devam edilir
- Asynchronous (Asenkron): Yanıt beklenmeden işlem tamamlanır
- Response İşleme (After Call - Sadece Synchronous): Gelen yanıt işlenir:
- Body üzerinde dönüşüm yapılır (NOT_CHANGE, REPLACE, CLEAR)
- Header ve parametreler manipüle edilir
- Data Manipulation kuralları uygulanır
- Cache’e kaydedilir (aktifse)
- Hata İşleme: Bağlantı hatası, timeout veya beklenmeyen yanıtlar için özelleştirilebilir HTTP durum kodu ve hata mesajı döndürülür.
Özellikler ve Yetenekler
Temel Özellikler
- Çağrı Tipi Seçimi: Synchronous (yanıt bekle) veya Asynchronous (fire-and-forget) mod desteği. Asenkron modda yanıt işleme yapılmaz.
- HTTP Method Desteği: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, TRACE tüm HTTP methodlarını destekler.
- Timeout Yönetimi: API çağrılarında maksimum bekleme süresini saniye cinsinden tanımlayarak sonsuz beklemeleri önler ve sistem kaynaklarını korur.
- 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
- Request/Response Manipülasyonu: Before Call ve After Call aşamalarında body, header ve parametreler üzerinde kapsamlı manipülasyon. XML, JSON, RAW, URL-Encoded formatlarını destekler.
- Data Manipulation: Kaynak ve hedef değişkenler arasında ADD (ekle), REPLACE (değiştir), DELETE (sil) operasyonları ile veri dönüştürme. Variable sistemini kullanarak dinamik veri işleme.
- SSL/TLS Certificate Desteği: Özel sertifikalarla güvenli (HTTPS) backend servislerine bağlanma. Certificate Manager entegrasyonu ile merkezi sertifika yönetimi.
- Cache Mekanizması: Distributed (dağıtık) veya Local (yerel) cache desteği. Variable bazlı cache key tanımlama, capacity ve TTL ayarları, null response’ları cache’leme seçeneği.
- Test Helper: API çağrısı için URL’yi otomatik oluşturma. Mevcut API Proxy’lerden veya Proxy Group’lardan endpoint seçimi, environment bazlı test yapma.
- 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ı
| Senaryo | Durum | Çözüm (Politika Uygulaması) | Beklenen Davranış / Sonuç |
|---|---|---|---|
| Mikroservis Entegrasyonu | Sipariş API’si, ödeme servisini çağırmalı | REST API Call politikası ile sipariş endpoint’ine gelen isteklerde ödeme servisine POST çağrısı yapılır. Body’de sipariş bilgileri gönderilir. | Ödeme servisi yanıtı alınır, başarılı ise sipariş onaylanır. Timeout 30 saniye. |
| Veri Zenginleştirme | Kullanıcı profil API’si, sadece ID ile gelir ancak detaylı bilgi gerekir | Gelen istek body’sindeki userId ile CRM sistemine GET çağrısı yapılır. Data Manipulation ile CRM yanıtı mevcut response’a eklenir. | İstemciye kullanıcı ID’si + tam profil bilgisi (ad, soyad, email) birleştirilmiş şekilde döner. |
| Authentication Token Yönetimi | Backend servisi API Key yerine JWT token bekliyor | Request Header’larından X-API-Key alınır, Authentication API’sine gönderilir. Dönen JWT token, Before Call aşamasında Authorization header’ına eklenir. | Backend servisi geçerli JWT token ile çağrılır. İstemci API Key kullanmaya devam eder. |
| Cache ile Performans | Ürün katalog API’si her çağrıda veritabanına gidiyor | REST API Call ile catalog servisi çağrılır. Cache aktif, capacity: 1000, TTL: 300 saniye. Cache By: “product.category” variable’ı. Storage: Distributed. | İlk çağrıda backend’e gidilir, sonuç 5 dakika cache’lenir. Aynı kategori için yapılan çağrılar cache’ten dönülür. |
| Async Log Gönderimi | Her API çağrısını harici log sistemine kaydetmek gerekiyor | Asynchronous REST API Call ile log servisine POST yapılır. Body’de request detayları gönderilir. Timeout: 5 saniye. | Log servisi yanıtı beklenmez, ana istek akışı kesintisiz devam eder. Fire-and-forget mantığı. |
| Üçüncü Parti API Gateway | Ödeme gateway’i özel header formatı bekliyor | Before Call aşamasında tüm header’lar silinir (removeAllHeadersBeforeCall: true). Yeni header’lar eklenir: X-Merchant-ID, X-Transaction-Type, Authorization (Bearer token). Body XML’den JSON’a dönüştürülür. | Ödeme gateway’i beklediği formatta istek alır, entegrasyon başarılı olur. |
| Certificate ile Güvenli İletişim | Backend servisi mutual TLS (mTLS) gerektiriyor | Certificate Enabled: true. Seçilen certificate: “Production_Client_Cert”. URL: https://secure-backend/api. Timeout: 60 saniye. | İstek client certificate ile gönderilir, backend servisi certificate’ı doğrular, güvenli iletişim sağlanır. |
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. Tanımlanan parametreler, politikanın çalışma şeklini (örneğin hangi IP’lerin izinli olacağı, coğrafi kısıtlamalar, koşullu aktivasyonlar vb.) doğrudan etkiler. Bu sayede politika hem kuruma özel gereksinimlere göre özelleştirilebilir hem de merkezi olarak yönetilebilir.Yeni API Call Politikası Oluşturma
Yapılandırma Adımları
| Adım | Açıklama / İşlem |
|---|---|
| Adım 1: Oluşturma Sayfasına Gitme | - Sol menüden Development → Global Settings → Global Policies → API Call bölümüne gidin. - 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: Örnek: Payment_Gateway_Call- Benzersiz isim girin, boşlukla başlamaz. - Sistem otomatik kontrol eder. Yeşil tik: kullanılabilir. Kırmızı çarpı: mevcut isim. Description (Açıklama): Örnek: “Ödeme gateway’ine sipariş onayı için API çağrısı yapar” - Maks. 1000 karakter. - Politikanın amacını açıklayın. |
| Adım 3: Çağrı Tipini ve Temel Ayarları Yapılandırma | Call Type (Çağrı Tipi): - SYNCHRONOUS: Yanıt beklenir, işleme devam edilir. Response işleme yapılır. - ASYNCHRONOUS: Fire-and-forget. Yanıt beklenmez, response işleme yapılmaz. HTTP Method Zorunlu: Dropdown’dan seçin (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, TRACE) Base URL Zorunlu: Örnek: https://api.payment-gateway.com/v2/charge- Test Helper (⚙️ ikonu) ile mevcut API Proxy’lerden URL seçebilirsiniz. Timeout Zorunlu: Saniye cinsinden. Örnek: 30 (30 saniye). Min: 1.- API yanıt vermezse bu süre sonunda timeout hatası dönülür. |
| Adım 4: Request (Before Call) Yapılandırması | BODY Sekmesi: Clear Body Before Call: Toggle ile aktif/pasif - Aktif: Gelen istek body’si temizlenir. - Pasif: Gelen body aynen kullanılır. Use Message Template (Clear Body aktifse): - Content Type: XML, JSON, RAW, URL_ENCODED - Body Content: Textarea’ya şablon girin. Variable kullanabilirsiniz: ${variable.name}- URL Encoded seçiliyse: Key-Value tablosu görünür. Request Data Manipulation: - [+ Add] butonuna tıklayın. - Operation: ADD, REPLACE, DELETE - Source: Value veya Variable - Target: Value veya Variable (ADD’de targetName zorunlu) HEADER Sekmesi: Remove All Headers Before Call: Toggle - Aktif: Tüm header’lar silinir. - Pasif: Header’lar korunur. Deleted Headers (Remove All pasifse): - Silinecek header adlarını liste halinde ekleyin: X-Old-HeaderNew Headers: - Name, Description, Value/Variable, Prefix (Variable seçiliyse: BEARER, BASIC vb.) - Örnek: Name: Authorization, Value: Bearer ${token.jwt}, Prefix: BEARERPARAMETER Sekmesi: - Header ile aynı mantık. Query parameter’leri için kullanılır. CACHE Sekmesi: Enable Cache: Toggle Apply By (Cache By): Variable seçin (örn: user.id, product.category)Capacity Zorunlu: Örnek: 1000 (1000 kayıt)TTL Zorunlu: Saniye cinsinden. Örnek: 300 (5 dakika)Cache Storage Type: DISTRIBUTED (dağıtık) veya LOCAL (yerel) Cache Null Responses: Checkbox - Null yanıtlar da cache’lensin mi? SETTINGS Sekmesi: Certificate Enabled: Toggle - Aktif: Certificate dropdown görünür. - Seçim: Certificate Manager’dan sertifika seçin. - [Add Certificate] butonu ile yeni sertifika ekleyebilirsiniz. |
| Adım 5: Response (After Call) Yapılandırması (Sadece SYNCHRONOUS) | BODY Sekmesi: After Call Body Operation Type: - NOT_CHANGE_BODY: Gelen yanıt aynen döndürülür. - REPLACE_BODY: Gelen yanıt tamamen değiştirilir. - CLEAR_BODY: Gelen yanıt temizlenir, yeni body oluşturulur. Use Message Template (CLEAR_BODY seçiliyse): - Content Type: XML, JSON - Body Content: Textarea’ya yanıt şablonu girin. Original Message Data Manipulation: - Before Call ile aynı mantık. Gelen yanıt üzerinde ADD, REPLACE, DELETE. HEADER ve PARAMETER Sekmeleri: - Request ile aynı yapı. After Call için header/parameter manipülasyonu. |
| Adım 6: 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/payment/* |
| Adım 7: Hata Mesajı Özelleştirme (İsteğe Bağlı) | - Error Message Customization sekmesine gidin. - API çağrısı başarısız olduğunda dönecek mesajı özelleştirin. Varsayılan: { "statusCode": 500, "message": "REST API call failed" }Özel: { "statusCode": 502, "errorCode": "PAYMENT_GATEWAY_ERROR", "message": "Ödeme servisi yanıt vermiyor", "timestamp": "${current.time}" } |
| Adım 8: Kaydetme | - Sağ üstteki [Save] butonuna tıklayın. Kontrol Listesi: Benzersiz isim. Zorunlu alanlar dolu. En az bir IP veya grup mevcut Sonuç: - Politika listeye eklenir. - API’lere bağlanabilir. - Global politikaysa otomatik uygulanır. |
Politikayı Silme
Bu politikanın silme adımları ve kullanımdayken uygulanacak işlemler için Politika Nedir? sayfasındaki Politikayı Silme bölümüne bakabilirsiniz.Politikayı Dışa/İçe Aktarma
Bu politikanın dışa aktarma (Export) adımları ve kullanılabilecek seçenekler için Politika Nedir? sayfasındaki Politikayı Dışa/İçe Aktarma bölümüne 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
Bu bölümde kullanıcı, API Call politikasının gelişmiş yönetim kabiliyetlerini kullanarak daha esnek, dinamik ve kurumsal seviyede kontrol elde eder.| Özellik | Açıklama ve Adımlar |
|---|---|
| Variable Bazlı Dynamic URL | URL içinde variable kullanarak dinamik endpoint’ler oluşturabilirsiniz. - Variable tanımlayın: backend.base.url = https://api.backend.com- URL alanına: ${backend.base.url}/users/${user.id}/profile- Runtime’da değerler otomatik doldurulur. |
| Chained API Calls (Zincir Çağrılar) | Birden fazla REST API Call politikasını sıralı çalıştırarak veri akışı oluşturabilirsiniz. - İlk politika ile Authentication API’sini çağırın, token alın. - Token’ı variable’a kaydedin: auth.token- İkinci politikada Authorization header’ına ${auth.token} ekleyin.- İkinci politika ile Data API’sini çağırın. |
| Conditional Caching | Sadece belirli durumlarda cache aktif olur. - Cache’i aktif edin. - Condition bölümünde: Header = X-Cache-Control, Equals = enable- İstemci cache istediğinde header göndererek cache’i aktif eder. |
İpuçları ve En İyi Uygulamalar
Yapılması Gerekenler ve En İyi Uygulamalar
| Kategori | Açıklama / Öneriler |
|---|---|
| URL Yönetimi | Kötü: URL’leri hard-code olarak yazma: https://api.prod.com/usersİyi: Environment variable kullanma: ${env.api.url}/usersEn İyi: Variable + Config ile ortam bazlı yönetim: Test ortamında ${backend.url} = https://test-api.com, Production’da https://prod-api.com |
| Timeout Değerleri | Kötü: Çok yüksek timeout (120 saniye) - Sistem kaynakları tükenir İyi: Ortalama timeout (30 saniye) - Çoğu durumda yeterli En İyi: Backend servisi response time’ına göre optimize edilmiş timeout. Database sorguları: 10 saniye, Harici API: 30 saniye, Ödeme: 60 saniye |
| Cache Stratejisi | Kötü: Tüm API’lere aynı cache ayarı - Gereksiz cache İyi: Endpoint bazlı cache - Ürün listesi: 5 dakika En İyi: Variable bazlı cache + Null response kontrolü. Cache By: user.tier → Premium user: 1 dakika, Free user: 10 dakika. Cache Null Responses: false (boş yanıtlar cache’lenmesin) |
| Error Handling | Kötü: Varsayılan hata mesajları - Kullanıcı anlamaz İyi: Özel hata mesajları - “Backend servisi yanıt vermiyor” En İyi: HTTP status code + custom error code + contextual message: { statusCode: 504, errorCode: "PAYMENT_TIMEOUT", message: "Ödeme servisi 30 saniye içinde yanıt vermedi", retryAfter: 60 } |
| Header Manipulation | Kötü: Tüm header’ları silip manuel ekleme - Güvenlik riski İyi: Sadece gerekli header’ları ekleme/silme En İyi: Remove All Headers: false. Sadece hassas header’ları sil (Authorization, Cookie). Backend’in ihtiyacı olan header’ları ekle. Trace için correlation-id ekle. |
Güvenlik En İyi Uygulamaları
| Güvenlik Alanı | Açıklama / Uyarılar |
|---|---|
| Certificate Kullanımı | Uyarı: HTTPS backend’lere certificate olmadan bağlanmak güvenlik açığı oluşturur. Öneri: Mutual TLS (mTLS) gerektiren sistemlere mutlaka certificate ekleyin. Certificate revoke kontrolü yapın. Expired sertifikalar uyarı verir. Kritik: Production ortamında self-signed certificate kullanmayın. |
| Hassas Veri İletimi | Uyarı: API Key, token, password gibi bilgileri body içinde plain text göndermeyin. Öneri: Hassas verileri Variable olarak tanımlayın, encrypted saklayın. Header’da gönderin: Authorization: Bearer ${secure.token}Kritik: Log’lara hassas veri düşmemesine dikkat edin. Data Manipulation’da password alanlarını mask edin. |
| Asynchronous Call Güvenliği | Uyarı: Asenkron çağrılarda yanıt kontrol edilemez, hata gözden kaçabilir. Öneri: Kritik operasyonlar için Synchronous kullanın. Asenkron sadece log, notification gibi yan işlemler için kullanın. Kritik: Ödeme, sipariş onayı gibi işlemler asıl yanıt alınmadan tamamlanmamalı. |
| Input Validation | Uyarı: Gelen istekleri doğrulamadan backend’e göndermeyin. Öneri: Before Call aşamasında input validation ekleyin. XSS, SQL Injection riskli karakterleri filtreleyin. Data Manipulation ile sanitization yapın. Kritik: Backend’in beklediği format dışında veri gönderilmemesini sağlayın. |
| Rate Limiting | Uyarı: REST API Call politikası rate limiting yapmaz, backend overload olabilir. Öneri: REST API Call ile birlikte Rate Limiting politikası kullanın. Backend sistemine aşırı yük atmayın. Kritik: DDoS koruması için API Gateway seviyesinde rate limiting şart. |
Kaçınılması Gerekenler
| Kategori | Açıklama / Uyarılar |
|---|---|
| Sonsuz Timeout | Neden kaçınılmalı: Timeout değeri çok yüksek olursa (örn: 300 saniye), yanıt vermeyen backend’ler sistem kaynaklarını tüketir. Connection pool dolabilir. Alternatif: Makul timeout değerleri kullanın (5-60 saniye arası). Backend servisi optimize edin. Gerekirse async call kullanın. |
| Cache Olmadan Yoğun Çağrı | Neden kaçınılmalı: Aynı veriyi defalarca çağırmak backend’i yorar, response time artar, maliyet artar. Alternatif: Sık değişmeyen veriler (ürün katalog, ayarlar) için cache aktif edin. TTL’yi veri güncelleme sıklığına göre ayarlayın. |
| Gereksiz Data Manipulation | Neden kaçınılmalı: Her request/response’da karmaşık data manipulation yapmak performansı düşürür. CPU kullanımı artar. Alternatif: Backend servisini değiştirerek veriyi istenen formatta göndermeyi tercih edin. Sadece gerektiğinde data manipulation kullanın. |
| Global Politikada Sık Değişiklik | Neden kaçınılmalı: Global politika birden fazla API’de kullanılıyorsa, bir değişiklik tüm API’leri etkiler. Production’da hata riski artar. Alternatif: Test ortamında global politikayı test edin. Kritik API’ler için local politika kullanın. Değişiklik öncesi backup alın. |
Performans İpuçları
| Kriter | Öneri / Etki |
|---|---|
| Connection Reuse | Öneri: Apinizer backend bağlantıları connection pool ile yönetir. Aynı backend’e birden fazla çağrı yapılıyorsa connection reuse edilir. Etki: Her çağrıda yeni TCP bağlantısı açılmaz, latency azalır. SSL handshake overhead’i düşer. |
| Cache Hit Ratio | Öneri: Cache capacity’yi çok düşük tutmayın. Yoğun kullanılan endpoint’lere yüksek capacity verin. Cache By ile doğru key seçimi yapın. Etki: Cache hit ratio %80+ olursa backend load %80 azalır. Response time 10-100x hızlanır. |
| Async vs Sync Seçimi | Öneri: Kritik olmayan, yavaş, yanıt gerektirmeyen işlemler için async kullanın (log, notification, analytics). Etki: Ana istek akışı bloklanmaz. End-user response time düşer. Backend timeout riski azalır. |
| Data Manipulation Optimizasyonu | Öneri: Büyük JSON/XML dosyalarında gereksiz parsing yapmayın. Sadece gerekli alanları manipüle edin. Variable kullanarak XPath/JSONPath ile direkt alana erişin. Etki: CPU kullanımı %50-70 azalır. Memory consumption düşer. Throughput artar. |
| Timeout Tuning | Öneri: Backend servisi average response time’ını ölçün. Timeout’u average + 2x standard deviation olarak ayarlayın. Örnek: Avg: 2s, StdDev: 1s → Timeout: 4s Etki: Gereksiz timeout oluşmaz. Yanıt vermeyen backend’ler hızlı fail eder. Resource leak önlenir. |
Sık Sorulan Sorular (SSS)
| Kategori | Soru | Cevap |
|---|---|---|
| Genel | REST API Call politikası ile API Proxy arasındaki fark nedir? | API Proxy: İstemciye sunulan public endpoint. REST API Call: Politika olarak başka bir backend API’sine çağrı yapar. Bir API Proxy içinde REST API Call politikası kullanılabilir. Örnek: İstemci → API Proxy (/payment) → REST API Call → Backend (/charge) |
| Genel | Aynı API Proxy’de birden fazla REST API Call politikası kullanabilir miyim? | Evet. Farklı condition’larla veya sıralı olarak birden fazla REST API Call politikası kullanabilirsiniz. Örnek: İlk politika authentication, ikinci politika data fetch. |
| Teknik | Synchronous ve Asynchronous arasındaki fark pratikte nedir? | Synchronous: İstek gönderilir, yanıt beklenir, yanıt işlenir, istemciye dönülür. Total time artar ama kontrol tam. Asynchronous: İstek gönderilir, yanıt beklenmez, hemen istemciye dönülür. Total time düşer ama backend başarı/hata bilgisi alınamaz. |
| Teknik | Cache’de veri bozulması veya stale data riski var mı? | TTL doğru ayarlanırsa risk minimumdur. TTL sonunda cache temizlenir. Manuel cache clear için Cache Policy kullanın. Critical data için TTL’yi düşük tutun (30-60 saniye). |
| Kullanım | Test Helper nedir, nasıl kullanılır? | Test Helper, REST API Call için URL oluşturmayı kolaylaştırır. Mevcut API Proxy’leri listeler, seçtiğiniz proxy’nin URL’ini otomatik doldurur. Environment seçimi yapabilirsiniz. ⚙️ ikonuna tıklayarak açılır. |
| Kullanım | Data Manipulation’da ADD ve REPLACE farkı nedir? | ADD: Yeni bir alan ekler. Örnek: Response JSON’a yeni alan ekle: response.user.fullName = ${user.firstName} + ${user.lastName}REPLACE: Mevcut alanı değiştirir. Örnek: request.body.price değerini ${discounted.price} ile değiştir. |
| Hata | ”PolicyRestApiCallConnectionException” hatası alıyorum. Çözüm? | Backend servisi erişilemiyor. Kontrol: URL doğru mu? Backend ayakta mı? Network firewall var mı? Certificate gerekiyor mu? Timeout çok düşük mü (artırın)? |
| Hata | Cache çalışmıyor, her çağrıda backend’e gidiyor. Neden? | Kontrol: Cache enabled mi? Capacity ve TTL tanımlı mı? Cache By variable doğru set edilmiş mi? Aynı cache key ile istek geliyor mu? Cache storage type distributed ise cache sunucusu ayakta mı? |
| Performans | REST API Call politikası performance overhead’i ne kadardır? | Minimal. Ek latency: Data manipulation varsa 5-20ms, yoksa 2ms’den az. Cache aktifse cache hit’te backend çağrısı olmaz, latency %90 düşer. Asynchronous modda overhead neredeyse sıfır. |