Yönlendirme Sekmesi (Routing Tab)
API Proxy, istemciden gelen mesajları karşılayıp varsa politikaları işlettikten sonra, mesajı Backend API'ye yönlendirir. Yönlendirme sekmesi, işte bu yönlendirme işleminin nasıl yapılacağının ayarlandığı sekmedir.
Yönlendirme Sekmesi ayarlarını içeren görsele aşağıda yer verilmiştir:
Eğer ilgili API Proxy bir Gruba dahilse ve API Proxy Group ekranından Ayarları İlgili API Proxy'lere Uygula seçeneği seçilmiş ise, yukarı görseldeki işaretlenmiş olan uyarıyla karşılaşılır.
Backend API Adreslerinin Yönetilmesi
API Proxy oluşturulurken Backend API'nin erişim adresi farklı şekillerde alınabilir:
- Eğer bir API Tanım Dosyası kullanılmışsa bu dosyanın içindeki adres ya da adreslerden en az biri kullanıcı tarafından seçilir.
- Eğer Empty API seçeneği ile API Proxy oluşturuluyorsa (örneğin code-first yaklaşımla geliştirilmiş bir Backend API için), Backend API'nin adresi kullanıcı tarafından girilir.
- Eğer API Creator (DB-2-API, Mock API ya da Script-2-API) ile oluşturulan bir API için API Proxy oluşturuluyorsa adres istenmez, Apinizer tarafından yönetilir. Bu tip API'ler için Yönlendirme Sekmesi kapalıdır.
Oluşturma aşamasında alınan adres bilgisi daha sonra değiştirilebilir, yeni adresler tanımlanabilir ya da var olanlar silinebilir. Bunun için Yönlendirme Sekmesi'ndeki Adresler (Addresses) bölümü kullanılır.
Adresi Güncelleme
Adresleri gösteren tablonun Adres (Address) kolonundaki Yapılandır (Configure) tuşuna tıklandığında açılan pencerede adres güncellenebilir.
Eğer API Proxy'nin tipi SOAP ise; bu kısımda eklenen/düzenlenen SOAP Type bilgisi WSDL'da port bilgisine yansıtılır.
Yeni Adres Ekleme
Yapılandır butonuyla açılan pencerenin en sağındaki kolon başlığı bölgesindeki 
tuşuna tıklandığında açılan pencereden yeni bir adres eklenebilir.
Koşullu Yönlendirme (Conditional Routing)
Adres güncelleme ya da ekleme işlemleri için açılan penceredeki Koşul (Condition) bölümü, istemciden gelen mesajların bu adrese gönderilmesi için koşul tanımlama olanağı verir. Böylece örneğin özel bir başlık ya da parametre değeri ile gelmeyen isteklerin tanımlı adreslerden sadece belirli bir ya da daha fazlasına yönlendirilmesi sağlanabilir.
Pratik bir kullanım senaryosu örneği, "test=true" parametresi ile gelen isteklerin test sunucusuna, bu parametreyi içermeyen isteklerin ise production sunucusuna yönlendirilmesi olabilir. Bir başka senaryo, isteklerin IP değerine göre farklı bölgelerdeki sunuculara yönlendirilmesi olarak düşünülebilir.
Adres Silme
Silinmek istenen adresin satır sonundaki açılır menüsünden Kaldır (Remove) seçeneği seçilerek adres silinir.
API Proxy'nin yönlendirme yapabilmesi için en az bir adres olması gerekir. Bu nedenle en son adres için silindikten sonra kaydet butonu pasif olur ve kaydetmeye izin vermez.
Yük Dengeleme (Load Balancing)
Backend API'deki yükün artması durumunda, aynı API/Web Servis başka bir sunucuya daha yüklenerek yükün dağıtılması mümkündür.
Yeni sunucunun istemcilerin erişimine açılması için herhangi bir ağ ayarı yapılmasına gerek yoktur, Apinizer üzerindeki Adresler (Addresses) kesimine eklenmesi yeterlidir. Apinizer, eğer bir Backend API için birden çok adres tanımlanmış ise bu adresler arasında yükü dağıtır.
Yük dengeleme için kullanılabilecek algoritmalardan hangisinin kullanılacağı kullanıcı tarafından belirlenebilir.
| Algoritma | Açıklama |
|---|---|
| Round Robin | İstek mesajları listedeki adreslere sıra ile gönderilir. Listenin sonuna gelindiğinde listenin başına dönülür ve aynı döngü devam eder. |
LRU (Least Recently Used) | İstek mesajları listedeki adresler arasındaki en uzun süre kullanılmayan sunucuya yönlendirir. |
Ağırlıklı (Weighted) | Kullanıcı tarafından adreslere ağırlıklar atanır. Bu ağırlık değerleri dikkate alınarak istekler sunuculara sırayla yönlendirilir. Örneğin; iki adresten birinin ağırlığı 1 diğerinin ağırlığı 2 ise ağırlığı 1 olan adrese 1 istek yönlendirilirken, ağırlığı 2 olan adrese 2 istek yönlendirilir. |
Rastgele (Random) | İstek mesajları rastgele seçilen adreslere yönlendirilir. |
Yük Dengeleme Tipi (Load Balancing Type) | Apinizer, her bir Ortam (Environment)'da birden çok Worker çalışacak şekilde biçimlendirilebilir. Böylece o Ortam'daki API Proxy'ler arasında yük dağıtılmış olur. Bu durumda, her bir Worker üzerindeki API Proxy'ler, Backend API adreslerini bilmek zorundadır. Yük Dengeleme Tipi parametresi, Backend API adresleri arasında yük dengeleme yapılırken hangisine kaç kez ya da en son gidildiği bilgisinin nasıl tutulacağını belirler. Eğer Basit (Single) seçilmişse, her Worker yük dengeleme adresini diğer Worker'lardan bağımsız olarak işletirken, Dağıtılmış (Distributed) seçildiği durumda Worker'lar dağıtılmış önbellek kullanarak aynı ve tek bir erişim verisi üzerinden yük dengeleme yaparlar. Buna göre Basit (Single) daha hızlı çalışırken, Dağıtılmış (Distributed) yük dengeleme algoritmasının doğru işletildiğini garanti edecek şekilde çalışmaktadır. |
Zaman Aşımı Süreleri (Timeouts)
Bir istek Backend API'ye belirli bir süre boyunca gönderilemezse ya da belirli bir süre içerisinde yanıt alınamazsa daha fazla beklenmeden isteğin sonlandırılması ve hata bildiriminde bulunulması ya da yükün devredilmesi gerekir.
Bu amaç için kullanılabilecek iki farklı zaman aşımı parametresi bulunmaktadır.
Bağlantı Zaman Aşımı (Connection Timeout)
Backend API'ye bağlanıp istek mesajını gönderebilmek için belirlenen azami bekleme süresidir. Saniye olarak verilir. Bu süre boyunca Backend API'ye erişilemez ise;
- Yeniden Deneme Sayısı (Retry Count) ve Başarısızlıkta Deneme Sayısı (Failover Retry Count) parametrelerinin değerlerine göre aynı adrese ya da varsa listedeki diğer adreslere yeni istek gönderilebilir,
- İstemciye hata döndürülebilir.
Okuma Zaman Aşımı (Read Timeout)
Backend API'den yanıt mesajını almak için belirlenen azami bekleme süresidir. Saniye olarak verilir. Bu süre boyunca Backend API'den yanıt alınamaz ise;
- Yeniden Deneme Sayısı (Retry Count) ve Başarısızlıkta Deneme Sayısı (Failover Retry Count) parametrelerinin değerlerine göre aynı adrese ya da varsa listedeki diğer adreslere yeni istek gönderilebilir,
- İstemciye hata döndürülebilir.
Yük Devretme (Failover)
Zaman aşımı sürelerinin aşılması ya da Backend API'den hata dönmesi durumunda istemciye hemen hata dönülmesi yerine aynı adrese ya da diğer adreslere tekrar istek gönderilerek işlemin başarılı olması sağlanmaya çalışılır.
Bunun için iki farklı parametre kullanılır:
Yeniden Deneme Sayısı (Retry Count)
Backend API'ye gönderilen istek ya da beklenen yanıt mesajı için zaman aşımı oluşursa veya Backend API'den hata dönerse, istemciye hata mesajı dönülmeden önce Yeniden Deneme Sayısı (Retry Count) parametresinin değeri kontrol edilir. Eğer bu değer 0'dan büyükse, Backend API'ye yeniden istek gönderilir. Bu işlem, bu parametrenin değeri kez yenilenir.
Başarısızlıkta Deneme Sayısı (Failover Retry Count)
Backend API'ye Yeniden Deneme Sayısı (Retry Count) kez mesaj gönderildiği halde hala zaman aşımı oluşuyor ya da Backend API'den hata mesajı dönüyorsa, Başarısızlıkta Deneme Sayısı (Failover Retry Count) parametresinin değeri kontrol edilir. Eğer bu değer 0'dan büyükse, diğer Backend API adreslerine istek gönderilir. Farklı adresleri deneme işlemi bu parametrenin değeri kez yenilenir. Her yeni adres için tek bir deneme yapılarak eğer başarılı sonuç alınamazsa bir sonraki adrese geçilir. Eğer tanımlı adres sayısı Başarısızlıkta Deneme Sayısı (Failover Retry Count) parametresinin değerinden küçükse, denenecek yeni adres kalmadığı için işlem sonlandırılır ve istemciye hata döndürülür.
Hata İçeren Yanıt Mesajının Korunması
Bir API Proxy için Genel Bakış (Overview) sekmesinde XML/JSON Hata Yanıt Şablonu bölümünde yapılan konfigürasyon ile, hata durumlarında istemciye nasıl bir hata mesajı döndürüleceğini belirleyen şablonlar tanımlanabilir. Bu hata şablonları, uygulanan politikalarla ilgili hataların da ele alınarak özelleştirilmesine imkan verir. Bununla birlikte, bazen Backend API'den dönen hata mesajı, istemci için anlamlı veri içerebilir ve dolayısıyla bu mesajın istemciye olduğu gibi döndürülmesi istenebilir. Böyle bir durumda Hedef API'den Hata Dönmesi Durumunda Yanıt Şablonunu Uygulama (Ignore Error Response Template In Case Of Error On Backend API) parametresinin kutusu işaretlenir. Bu parametre işaretlendiği zaman, Hata Yanıt Şablonu bölümünde tanımlanan şablonlar yalnızca Backend API'den hatalı mesaj dönmesi durumunda işleme alınmaz. Ancak örneğin herhangi bir politikadan kaynaklanan hata yanıtları için bu şablonlar kullanılacaktır.
Hata İşleme
Hata İşleme Backend adresinden dönen sonucun Başarılı mı yoksa Hatalı mı değerlendirileceğini belirlemek için kullanılır.
Hata işleme türü ve koşulunu içeren görsele aşağıda yer verilmiştir:
Mesajın durumuna karar vermek için üç seçenek bulunur; varsayılan ayarlar (default settings), gelişmiş ayarlar (advanced settings) ve durum kodu listesi (status code list).
- Varsayılan ayarlar seçilirse, bu durumda dönen mesajın durumu "HTTP durum kodu >= 400" mü diye kontrol edilir. Koşul sağlanmış ise mesajın durumu hatalı olarak değerlendirilir.
- Gelişmiş ayarlar seçilirse, bu durumda dönen mesajın üzerinde belirtilen koşul sağlanıyor mu diye kontrol edilir. Koşul sağlanmış ise mesajın durumu hatalı olarak değerlendirilir. Örneğin; "(HTTP durum kodu = 500 or HTTP durum kodu = 501) and (mesaj gövdesi contains "error") ..vb" şeklinde koşul yazılabilir.
- Durum kodu listesi seçilirse, bu durumda dönen mesajın HTTP durum kodu, belirtilen liste içerisinde yer alıyor mu diye kontrol edilir. Koşul sağlanmış ise mesajın durumu hatalı olarak değerlendirilir.
Beklenmeyen durumlar (yani hata koşuluna uyan dönüşler) için yanıt hattındaki politikalar çalıştırılmaz.
Bağlantı Havuzu Yönetimi
Bağlantı Havuzu Yönetim ayarlarını içeren görsele aşağıda yer verilmiştir:
Bağlantı Havuz Yönetimi konfigürasyonu için kullanılan alanlar aşağıda görülmektedir.
| Alan | Açıklama | |
|---|---|---|
Bağlantı Havuz Yönetim Türü (Connection Pool Management Type) | Bağlantı Havuz Yönetimi seçenekleri:
| |
Bağlantı Havuzu Boyutu (Custom Connection Pool Size) | Bu alan Bağlantı Havuz Yönetim Türü olarak Özelleştir (Custom) seçilirse aktif olur. Burada belirlenen sayıya göre bu API Proxy'e özel Bağlantı Havuzu oluşturulur. | |
SOAP Action ve Namespace Bilgisini Düzelt
SOAP ve Rest2Soap servislerde aktif olan bu seçenek ile SOAP action ve namespacelerinin WSDL'a göre varsayılan olarak düzeltilmesi işlemi gerçekleştirilir.
Ayarın devre dışı bırakılması durumunda istemcinin gönderdiği istek üzerinde bir değişiklik yapılmaz.
SOAP Action ve Namespace Bilgisini Düzeltme ayarını içeren görsele aşağıda yer verilmiştir:
Devre Kesici (Circuit Breaker)
İstemcilerden API'lere yapılan istekler yavaş ağ bağlantıları, zaman aşımları ve kaynakların aşırı yüklenmesi veya geçici olarak devre dışı bırakılması gibi geçici hatalardan dolayı başarısız olabilir. Bu gibi hataların nedenleri kısa sürede kendiliğinden ortadan kalkabilir. Ancak hataların nedenlerinin ortadan kalkabilmesi için sunuculara zaman tanınması gerekir. Bir mikro servis mimari şablonu (microservice architecture pattern) olan Devre Kesici (Circuit Breaker) bu amaca hizmet eder.
Devre Kesici, yük dağılımı yapılan bir sistemde mevcut uç noktaları izleyerek, uç nokta cevaplarında herhangi bir anormallik olması durumunda ilgili uç noktaya erişimi bir süreliğine durdurur.
Devre Kesici yapılandırma ayarlarını içeren görsele aşağıda yer verilmiştir:
Devre Kesicinin kullanılabilmesi için adresler bölümünde Backend API için en az iki adres tanımlanmış olmalıdır.
Devre Kesici konfigürasyonu için kullanılan parametreler aşağıda görülmektedir.
| Alan | Açıklama | |
|---|---|---|
Devre Kesiciyi Aktive Et (Enable Circuit Breaker) | Devre Kesiciyi aktif hale getirerek konfigürasyon parametrelerini girilebilmesinin sağlar. | |
Hata Penceresi (Error Window) | Backend API adreslerinin hatalar için izlenme süresini belirtir. Saniye olarak girilir. | |
Hata Eşiği Değeri (Error Threshold Value) | Takip edilen süre içerisinde ne kadar hatanın kabul edileceğini belirtir. Hata eşiği aşıldığında o Backend API adresine Uyuma Penceresi parametresi ile belirtilen süre boyunca yeni istek gönderilmez. | |
Hata Eşiği Tipi (Error Threshold Type) | Hata sayısının nasıl ele alınacağını belirtir.
olsun. Buna göre,
| |
Uyuma Penceresi (Sleep Window) | Hata alınan ve Hata Eşiği Değeri aşılan Backend API adresine ne kadar süre ile yeni bir istek gönderilmeyeceğini belirtir. Bu süre boyunca gelen istekler diğer adres ya da adreslere yönlendirilir. Süre bitiminde bu adrese de yeniden istek göndermeye başlanır. | |
Yarı Açığı Aktive Et (Enable Half Open) | Bu seçenek işaretlenirse, Uyuma Penceresi parametresi ile belirtilen süre geçtikten sonra ilgili adrese 1 adet istek gönderilerek o adresteki sorunun ortadan kalkıp kalkmadığına bakılır. Dönen sonuç hatalı ise bu adres Uyuma Penceresi süresi boyunca tekrar yeni isteklere kapatılır. Bu seçenek işaretlenmezse, Uyuma Penceresi parametresi ile belirtilen süre geçtikten sonra ilgili adresin değerleri sıfırlanır ve bu adres için Hata Penceresi süresince izleme yeniden başlar. | |
Devre Kesici her adres için ayrı ayrı uygulanır. Hata eşiği ve süresi aşıldığında devre kesici yalnızca ilgili adresteki uç noktaya erişimi engeller.
İstemci Akış Kesici (Client Flow Banner)
Bir istemcinin Backend API'den üst üste hata alması beklenen bir durum değildir. Böyle bir durum oluşuyorsa büyük olasılıkla bir yazılım hatası ya da güncelleme ihtiyacı söz konusudur. Sürekli hata aldığı halde tekrar tekrar istek göndermeye devam eden istemcilerin Backend API'ye erişimi İstemci Akış Kesici ile kısıtlanabilir. Böylece diğer istemcilerin bu durumdan olumsuz etkilenmesi engellenir.
İstemci Akış Kesici yapılandırma ayarlarını içeren görsele aşağıda yer verilmiştir:
İstemci Akış Kesici konfigürasyonu için kullanılan parametreler aşağıda görülmektedir.
Alan | Açıklama | |
|---|---|---|
İstemci Akış Kesiciyi Aktive Et (Enable Client Flow Banner) | İstemci Akış Kesiciyi aktif hale getirerek konfigürasyon parametrelerinin girilebilmesini sağlar. | |
İstemci Kimliği Değişkeni (Variable for Client Identity) | Erişimi duraklatılacak istemci kimliğinin, mesajın neresinden alınacak veri ile belirleneceğidir. | |
Hata Penceresi (Error Window) | İstemciye dönen hatalar için izlenme süresini belirtir. Saniye olarak girilir. | |
Hata Eşiği Değeri (Error Threshold Value) | Takip edilen süre içerisinde ne kadar hatanın kabul edileceğini belirtir. Hata eşiği aşıldığında o istemciden Yasaklama Süresi parametresi ile belirtilen süre boyunca yeni istek kabul edilmez. | |
Hata Eşiği Tipi (Error Threshold Type) | Hata sayısının nasıl ele alınacağını belirtir.
olsun. Buna göre,
| |
Yasaklama Süresi (Banning Window) | İstemciden ne kadar süre ile yeni bir istek kabul edilmeyeceğini belirtir. Saniye olarak girilir. | |
İndirme (Download)
API Proxy'nin sonucunda dönecek olan verinin indirilebilir olması istenirse bu özellik aktif hale getirilir.
Hangi yanıt mesajının indirilebilir olduğuna dönüş değerindeki Content-Type başlık değerine bakılarak karar verilir. Buradaki değerler sistem ayarlarında yer alan Byte Array Content Types sayfasındaki listede yer alıyorsa dönen değerin indirilebilir olduğuna karar verilir.
İndirme seçeneği aktifleştirilmişse;
- Eğer erişilen uç noktanın (endpoint) yanıt içerik tipi (response content type) indirilebilir içerik ise dosya olarak indirilir.
- Eğer erişilen uç noktanın yanıt içerik tipi indirilebilir içerik değil ise istek bundan etkilenmez, normal akış devam eder.
İndirme seçeneği aktifleştirilmemişse;
- Eğer erişilen uç noktanın yanıt içerik tipi indirilebilir içerik ise, içerik Base64 ile kodlanarak String olarak döndürülür.
- Eğer erişilen uç noktanın yanıt içerik tipi indirilebilir içerik değil ise istek bundan etkilenmez, normal akış devam eder.
Proxy Sunucu (Proxy Server)
Bazı durumlarda Backend API adresi bir vekil sunucunun (proxy server) arkasında olabilir. Böyle bir senaryoda gerekli olan Proxy sunucusu ayarları, Yönlendirme sekmesinin Proxy Sunucu bölümünden yapılır.
Proxy Sunucu yapılandırma ayarlarını içeren görsele aşağıda yer verilmiştir:
Proxy Sunucu konfigürasyonu için kullanılan parametreler aşağıda görülmektedir.
| Alan | Açıklama | |
|---|---|---|
Proxy Sunucu Kullan (Use Proxy Server) | Proxy Sunucu ayarlarını aktif hale getirerek konfigürasyon parametrelerinin girilebilmesini sağlar. | |
Bilgiyi istek mesajının başlığından al (Get information from request header) | Proxy sunucu için "X-Proxy-Host" ve "X-Proxy-Port" başlıkları, yetkilendirme gerekiyorsa "Proxy-Authorization" başlığı kullanılır. "Proxy-Authorization" başlığı proxy sunucuya bağlanmak için kullanılan kullanıcının yetkilendirmesinde kullanılır. Kullanıcı adı ve şifrenin iki nokta ile birleştirilip Base64 ile kodlanması ile oluşturulur. | |
| Host | Proxy sunucunun adı ya da IP'si girilir. | |
| Port | Proxy sunucunun portu girilir. | |
Proxy Sunucu İçin Yetkilendirme Gerekli (Proxy Server requires Authorization) | Proxy sunucu erişimi için yetkilendirme gerekiyorsa aktifleştirilir. | |
Kullanıcı Adı (Username) | Proxy sunucuya erişim yetkisi olan kullanıcı adı girilir. | |
Parola (Password) | Proxy sunucuya erişim yetkisi olan kullanıcı adının parolası girilir. | |
mTLS Ayarı
Bu ayar etkinleştirildiğinde seçili mTLS ayarları isteğe uygulanır.
Böylece Apinizer'dan hedef hizmete gönderim yapacak olan Apinizer istemcisi, hedef hizmetin sertifikasını doğrular ve kendisinin de bir sertifikası olduğunu ve hedef hizmet tarafından doğrulanması gerektiğini belirtir.
Hedef hizmet de istemcinin sertifikasını doğrular ve bu sayede istemci ile güvenli bir iletişim kurulmuş olur.
mTLS yapılandırma ayarlarını içeren görsele aşağıda yer verilmiştir:
mTLS konfigürasyonu için kullanılan parametreler aşağıda görülmektedir.
| Alan | Açıklama | |
|---|---|---|
Keystore | Keystore seçilir. Eğer daha önce tanımlı değil ise yandaki + butonuna basarak yeni bir tane oluşturulabilir. | |
| Truststore | Truststore seçilir. Eğer daha önce tanımlı değil ise yandaki + butonuna basarak yeni bir tane oluşturulabilir. | |
Desteklenen Protokol Listesi (Supported Protocol List) | Desteklenen protokoller seçilir. Seçenekler:
| |
Hostname Doğrulama Tipi (Hostname Verifier Type) | Noop Hostname Doğrulama, SSL/TLS bağlantılarında güvenlik riski oluşturabilecek hostname doğrulamasını devre dışı bırakır. Bir saldırganın SSL/TLS iletişimini kesebileceği ve sunucunun kimliğine bürünebileceği man-in-the-middle (MITM) saldırılarını önlemek için sunucunun hostname'ini doğrulamak önemlidir. Noop Hostname Doğrulama kullanmak yerine, Apache HttpComponents istemci çerçevesi tarafından sağlanan aşağıdaki hostname doğrulama uygulamalarından birini kullanabilirsiniz:
| |
mTLS ayarları etkin olduğunda routing'de var olan, ortam ayarlarında değerleri belirtilen "http connection pool" devre dışı bırakılır.
NTLM Ayarı
Bu ayar etkinleştirildiğinde seçili NTLM ayarları isteğe uygulanır.
NTLM yapılandırma ayarlarını içeren görsele aşağıda yer verilmiştir:
NTLM konfigürasyonu için kullanılan parametreler aşağıda görülmektedir.
| Alan | Açıklama | |
|---|---|---|
Domain | NTLM ayarına ait domain bilgisidir. | |
Kullanıcı Adı (Username) | NTLM ayarına ait kullanıcı adı bilgisidir. | |
Şifre (Password) | NTLM ayarına ait password bilgisidir. | |
Workstation | NTLM ayarına ait workstation bilgisidir. | |
Hata Mesajlarını Özelleştirin (Customize Error Messages)
Poliçelerden hata fırlatıldığında Apinizer, kullanıcıya özelleştirilme yapılmamış ise varsayılan hata mesajını gönderir. Hata mesajlarının özelleştirilmesi hakkında daha fazla bilgi almak için tıklayınız.
Önemli Notlar:
Yönlendirme sekmesinde yapılan değişiklikler kaydedildiği zaman API Proxy için Yeniden Yükle (Redeploy Required) tuşu aktif olur. Bu tuşa tıklanana kadar yapılan değişiklikler geçitlere yansıtılmaz.
İstemciden gelen şu başlıklar Backend API'ye gönderilmez
Content-Length
Host
User-Agent
Connection
Keep-Alive
Proxy-Authenticate
Proxy-Authorization
TE
Trailers
Upgrade
İstemciden gelen Content-Encoding, Transfer-Encoding başlıkları "gzip" değeri içeriyorsa mesaj gövdesi Backend API'ye gzip yapılarak gönderilir.
İstemciden gelen Content-Encoding, Transfer-Encoding başlıkları "deflate" değeri içeriyorsa mesaj gövdesi Backend API'ye deflate yapılarak gönderilir.
İstemciden gelen Accept-Encoding veya Backend API'den dönen Content-Encoding, Transfer-Encoding yanıt başlıkları "gzip" değeri içeriyorsa mesaj gövdesi istemciye gzip yapılarak gönderilir.
İstemciden gelen Accept-Encoding veya Backend API'den dönen Accept-Encoding, Content-Encoding, Transfer-Encoding yanıt başlıkları "deflate" değeri içeriyorsa mesaj gövdesi istemciye deflate yapılarak gönderilir.
- Gzip ya da Deflate işlemi tüm yanıt politikaları işletildikten sonra mesaj istemciye iletilmeden hemen önce uygulanır. Böylece politikaların çalışması etkilenmemiş olur.