HTTP Yönlendirme

​

Yönlendirme/Upstream Ayarlarının Etkinleştirilmesi

Yönlendirme/upstream ayarlarının etkinleştirme ayarlarını içeren görsele aşağıda yer verilmiştir: Yönlendirme/upstream ayarlarının etkinleştirilmesi için kullanılan parametreler aşağıda görülmektedir. Yönlendirme Sekmesi ayarlarını içeren görsele aşağıda yer verilmiştir:

​

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 No-Spec 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.

​

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. Yeni adres ekleme penceresinde:

• Adres alanına backend API adresi girilir veya ortam değişkeni kullanılır
• Adres alanının sağındaki liste ikonu butonuna tıklanarak Ortam Değişkenleri Seçim Dialog’u açılabilir
• Seçilen ortam değişkeni panoya kopyalanır ve adres alanına yapıştırılır
• Koşul bölümü ile koşullu yönlendirme tanımlanabilir

​

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 bu değer otomatik olarak bulunduğu ortama göre değişmesi isteniyorsa Ortam Değişkenleri (Environment Variable) içinden seçim yapılabilir. Adres giriş alanının sağında bulunan liste ikonu butonuna tıklandığında Ortam Değişkenleri Seçim Dialog’u açılır. Bu dialog üzerinden projede tanımlı tüm ortam değişkenleri (Environment Variables) görüntülenebilir ve seçilebilir. Adres giriş alanının sağında bulunan liste ikonu butonuna tıklandığında Ortam Değişkenleri Seçim Dialog’u açılır. Bu dialog üzerinden projede tanımlı tüm ortam değişkenleri (Environment Variables) görüntülenebilir ve seçilebilir. Ortam Değişkenleri Seçim Dialog’unda:

• Tüm ortam değişkenleri listelenir (Global ve Environment-Specific)
• Arama kutusu ile değişken adı veya açıklamasına göre filtreleme yapılabilir
• Her değişken için Key Name, Açıklama , Tip bilgileri görüntülenir
• Kopyala (Copy) butonu ile seçilen değişkenin formatı (${variableName}) otomatik olarak panoya kopyalanır
• Kopyalanan değer adres alanına yapıştırılarak kullanılabilir

Örnek Kullanım:

• Ortam değişkeni: BACKEND_URL = dev-api.example.com (Development ortamı için)
• Ortam değişkeni: BACKEND_URL = api.example.com (Production ortamı için)
• Adres alanına girilen değer: ${BACKEND_URL}
• Runtime’da Development ortamında: dev-api.example.com
• Runtime’da Production ortamında: api.example.com

​

Koşullu Yönlendirme

Adres güncelleme ya da ekleme işlemleri için açılan penceredeki **Koşul ** 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 ** seçeneği seçilerek adres silinir.

​

Yük Dengeleme

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.

​

Sticky Session

Sticky Session mekanizması, aynı istemcinin her zaman aynı backend’e yönlendirilmesini sağlar. Bu mekanizma, session state, cache locality veya backend-specific data consistency gibi senaryolarda kullanılabilir. Apinizer üç farklı sticky session tipini destekler: COOKIE_ONLY, IP_HASH ve HYBRID. Cookie-based sticky session, HMAC-SHA256 ile imzalanmış güvenli cookie’ler kullanır ve circuit breaker ile entegre çalışarak unhealthy backend’leri otomatik olarak atlar.

​

Bağlantı Ayarları Tanımlama

Bağlantı ayarları konfigürasyonu için kullanılan parametreler aşağıda görülmektedir.

​

Devre Kesici

İ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 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. 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.

​

Health Check ile Otomatik Failback

Active Health Check mekanizması, backend’lerin sağlık durumunu periyodik olarak kontrol eder ve circuit breaker ile entegre çalışarak otomatik yük devretme sağlar. Bu mekanizma sayesinde unhealthy backend’ler otomatik olarak trafikten çıkarılır ve sağlıklı hale geldiklerinde tekrar trafiğe dahil edilir.

​

Health Check Nasıl Çalışır?

Health check mekanizması şu şekilde çalışır:

1. Periyodik Kontrol: Her backend için belirlenen interval süresinde (varsayılan: 30 saniye) health check endpoint’ine istek gönderilir
2. Sağlık Durumu Takibi: Her health check sonucuna göre backend’in sağlık durumu takip edilir
3. Unhealthy Tespiti: Ardışık başarısızlık sayısı fail threshold’u (varsayılan: 3) aştığında backend unhealthy olarak işaretlenir
4. Otomatik Devre Dışı Bırakma: Unhealthy backend’ler circuit breaker ile otomatik olarak trafikten çıkarılır
5. Otomatik Recovery: Ardışık başarı sayısı pass threshold’u (varsayılan: 2) aştığında backend tekrar healthy olarak işaretlenir ve trafiğe dahil edilir

​

Health Check Parametreleri

Health check parametreleri routing seviyesinde yapılandırılır ve tüm backend adresleri için geçerlidir:

​

Health Check → Circuit Breaker Koordinasyonu

Health check mekanizması, circuit breaker ile koordineli çalışarak backend’lerin otomatik olarak devre dışı bırakılmasını ve tekrar aktif hale getirilmesini sağlar:

• Backend Unhealthy: Health check fail threshold’u aştığında, circuit breaker otomatik olarak OPEN durumuna geçer ve backend trafikten çıkarılır
• Backend Healthy: Health check pass threshold’u aştığında, circuit breaker otomatik olarak CLOSED durumuna geçer ve backend tekrar trafiğe dahil edilir
• Load Balancing Entegrasyonu: Load balancing sırasında sadece healthy backend’ler seçilir, unhealthy backend’ler otomatik olarak filtrelenir

​

Health Check Lifecycle Yönetimi

API Proxy deploy, update veya undeploy edildiğinde, health check kayıtları otomatik olarak yönetilir:

• Deploy/Update: Yeni backend’ler eklenir, silinen backend’ler kaldırılır, değişmeyen backend’lerin config’i güncellenir (health status korunur)
• Undeploy: Tüm backend’lerin health check kayıtları temizlenir

​

Tekrar Deneme ve Yük Devretme

Backend API’ye gönderilen isteklerin başarısız olması durumunda otomatik olarak tekrar deneme ve yük devretme mekanizmaları devreye girer. Bu mekanizmalar sayesinde geçici hatalar otomatik olarak yönetilir ve yüksek erişilebilirlik sağlanır.

​

Tekrar Deneme (Retry) Mekanizması

Tekrar Deneme (Retry) mekanizması, backend’e gönderilen isteklerin başarısız olması durumunda aynı backend adresine belirli sayıda tekrar deneme yapılmasını sağlar.

​

Retry Parametreleri

​

Retry Akışı

Retry mekanizması şu durumlarda devreye girer:

• Zaman Aşımı: Bağlantı zaman aşımı veya okuma zaman aşımı oluştuğunda
• Hata Kodları: Backend’den HTTP hata kodları (4xx, 5xx) döndüğünde
• Bağlantı Hataları: UnknownHostException, MalformedURLException gibi bağlantı hatalarında

Retry mekanizması şu adımlarla çalışır:

1. İlk istek gönderilir ve sonuç kontrol edilir:
   • İstek başarılıysa: İşlem tamamlanır
   • İstek başarısızsa: Retry mekanizmasına geçilir
2. Retry mekanizması:
   • Retry count 0 ise: Failover mekanizmasına geçilir
   • Retry count 0’dan büyükse: Retry döngüsüne girilir
3. Retry döngüsü (i = 1’den retry count’a kadar):
   • Retry delay aktifse: Belirtilen süre beklenir (exponential backoff veya fixed delay)
   • İstek tekrar gönderilir
   • İstek başarılıysa: İşlem tamamlanır
   • İstek başarısızsa ve i < retry count ise: i artırılır ve döngü devam eder
   • İstek başarısızsa ve i = retry count ise: Failover mekanizmasına geçilir

​

Yük Devretme (Failover) Mekanizması

Yük Devretme (Failover) mekanizması, bir backend adresinin başarısız olması durumunda isteğin otomatik olarak diğer backend adreslerine (FAILOVER_ONLY tipindeki adresler) yönlendirilmesini sağlar.

​

Failover Mantığı

Failover mekanizması basit ve net bir mantıkla çalışır:

1. İlk İstek: PRIMARY adreslere gönderilir (load balancing ile)
2. Başarısızlık Durumu: İlk istek başarısız olursa ve failoverOnlyEnabled=true ise
3. Failover Adresleri: FAILOVER_ONLY tipindeki adreslere sırayla istek gönderilir
4. Failover Retry: Her failover adresi için failoverRetryCount kadar deneme yapılır

​

Failover Akışı

Failover mekanizması şu adımlarla çalışır:

1. PRIMARY backend’e istek gönderilir ve retry count kadar deneme yapılır:
   • İstek başarılıysa: İşlem tamamlanır
   • Tüm denemeler başarısızsa: Failover kontrolüne geçilir
2. Failover kontrolü:
   • failoverOnlyEnabled = false veya null ise: Hata döndürülür
   • failoverOnlyEnabled = true ise: FAILOVER_ONLY tipindeki adreslere geçilir
3. FAILOVER_ONLY adresleri (sırayla denenir):
   • İlk failover adresi seçilir (health check ile filtrelenmiş healthy adresler arasından)
   • Failover retry count kadar deneme yapılır
   • İstek başarılıysa: İşlem tamamlanır
   • İstek başarısızsa: Sonraki failover adresine geçilir
4. Tüm failover adresleri denenene kadar:
   • Her failover adresi için failover retry count kadar deneme yapılır
   • Başarılı olan ilk adres kullanılır ve işlem tamamlanır
   • Tüm failover adresleri başarısız olursa: Hata döndürülür

​

Adres Tipleri

​

Server Side Streaming (SSE)

Yanıt ayarlarında Server Side Streaming özelliği aktive edildiğinde, özellikle OpenAI, Claude, Gemini gibi HTTP yanıtlarını Stream olarak dönen API’lerin yanıtının istemciye toplu olarak değil parça parça iletilebilmesi sağlanır. Bu yöntemle istemci, yanıtı daha hızlı ve kesintisiz şekilde alabilir. SSE özelliği etkinleştirildiğinde bağlantı havuzu (Connection Pool) ve yeniden deneme (Retry) mekanizmaları devre dışı kalır. Ayrıca, yanıt hattında gönderilen parçalı veriler log trafiğinde kayıt altına alınmaz ve görüntülenemez. SSE uzun süreli açık bağlantılar oluşturduğundan, bağlantı zaman aşımı ayarları dikkatle yapılandırılmalıdır.

​

İndirme

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 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

Bazı durumlarda Backend API adresi bir vekil sunucunun 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 konfigürasyonu için kullanılan parametreler aşağıda görülmektedir.

​

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 konfigürasyonu için kullanılan parametreler aşağıda görülmektedir.

​

NTLM Ayarı

Bu ayar etkinleştirildiğinde seçili NTLM ayarları isteğe uygulanır. NTLM konfigürasyonu için kullanılan parametreler aşağıda görülmektedir.

​

Hata Mesajlarını Özelleştirin

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

• İstemciden gelen Content-Encoding, Transfer-Encoding başlıkları “gzip,deflate,br,zstd,compress” değerlerinden birini içeriyorsa, mesaj gövdesi ilk bulunan algoritma ile açılır ve tüm istek hattı politikaları uygulandıktan sonra Backend API’ye yine ilk bulunan sıkıştırma algoritması uygulanarak gönderilir.
• Backend API’den dönen Content-Encoding, Transfer-Encoding yanıt başlıkları “gzip,deflate,br,zstd,compress” değerlerinden birini içeriyorsa, mesaj gövdesi ilk bulunan algoritma ile açılır ve tüm yanıt hattı politikaları uygulandıktan sonra yine ilk bulunan sıkıştırma algoritması uygulanarak istemciye gönderilir.
• Böylece politikaların çalışması sıkıştırılmamış veri üzerinde olur.