Modern uygulama mimarileri sürekli evrim halindedir. API v1 olarak doğan endpoint v3'e ulaşır, monolith arkasındaki path yapısı microservice ayrımı sonrası değişir, B2B partner farklı URL şemasına alışkındır veya modernleştirme projesi yeni bir path düzeni dayatır. Her değişiklikte istemci tarafını veya kurum servisini baştan yapılandırmak isterseniz proje teknik iş olmaktan çıkar, uzun bir koordinasyon sürecine dönüşür.
Klasik yaklaşım iki kötü seçenek sunar. Birincisi kurum servisine yeni path desteği eklemektir; eski endpoint'leri korurken yeni endpoint'leri de yazmak kod karmaşıklığını ve test yükünü artırır. İkincisi istemcileri veya partnerleri yeni path'e geçmeye zorlamaktır; bu da operasyonel sürtüşme, sözleşme değişikliği, mobil uygulama güncellemesi ve uzun geçiş takvimi anlamına gelir.
Doğru model, istek-yanıt akışında kontrollü bir yeniden yazma katmanı kurmaktır. Bu katman istemciden gelen path'i kurum servisinin anladığı path'e dönüştürür; gerekirse yanıt gövdesindeki iç path'leri istemcinin beklediği dış path'lere geri yazar. Kurum servisi içeride modernleşirken, istemci veya partner kendi bildiği URL düzeniyle çalışmaya devam eder.
Bu katmanın güçlü olması için üç şart vardır. Birincisi esnek bul-değiştir mantığıdır: sabit path, prefix değişimi, query koruma ve FX tabanlı string dönüşümleri desteklenmelidir. İkincisi koşullu uygulamadır: kural her isteğe değil, yalnızca doğru Host, metod, IP, cookie, header veya FX koşulu eşleştiğinde çalışmalıdır. Üçüncüsü yanıt gövdesiyle çift yönlü eşleştirmedir; aksi halde kurum servisinin döndürdüğü iç linkler istemci tarafında kırık URL'ye dönüşür.
TR7 URL ve Path Düzenleme bu modeli sağlar: set_path, set_pathq ve normalize_uri eylemleri; FX STRREPLACE / STRREPLACEALL kalıpları; FX/ACL koşullu uygulama ve modifyResponse ile çift yönlü path eşleştirme, şeffaf backend path remap mimarisinin temelini oluşturur.
TR7 URL düzenleme katmanı, basit path değiştirmenin ötesinde uygulama mimarisi katmanları arasında kontrollü bir köprü kurar.
İstemciden gelen `/api/v1/users/123` isteği kurum servisinin beklediği `/internal/v3/users/123` path'ine dönüştürülebilir. set_path yalnızca path'i değiştirir; set_pathq path ve query bilgisini birlikte yeniden yazar. Böylece istemci eski URL düzenini kullanırken kurum servisi yeni mimariyle çalışır.
Sabit path değişikliği yeterli olmadığında FX ifade dili devreye girer. STRREPLACE ve STRREPLACEALL fonksiyonlarıyla prefix, suffix veya path içindeki belirli bölümler dönüştürülür. Operatör değişkenleri, find-replace alanlarını ve koşulları aynı kural modelinde kullanabilir.
Her yeniden yazma kuralı FX/ACL koşulu ile sınırlandırılabilir. Kural yalnızca belirli Host, metod, kaynak IP, cookie, header veya FX değişkeni eşleştiğinde çalışır. Aynı vService altında farklı path dönüşümleri farklı koşullarla paralel yönetilebilir.
İstek path'ini değiştirmek çoğu zaman tek başına yeterli değildir; kurum servisi yanıt gövdesinde iç path'ler döndürebilir. modifyResponse ile HTML linkleri, JSON href alanları veya metin içindeki iç path'ler dış path formatına geri yazılır. Sonuç, istemci açısından tamamen şeffaf backend path remap mimarisidir.
URL path yeniden yazma, tek bir aksiyondan ibaret değildir; migration, uyumluluk ve çift yönlü path gizleme desenleri için temel yapı taşıdır.
set_path, gelen isteğin path bölümünü yeni bir path değeriyle değiştirir. Yeni değer statik yazılabilir veya `%HOST`, `%PATH`, `%METHOD`, `%SRCIP` gibi smart content değişkenleriyle dinamik hale getirilebilir. Query string set_path kullanıldığında korunmaz; query bilgisini korumak gerekiyorsa set_pathq tercih edilir. Bu özellik eski dış URL yapısını içerideki yeni servis düzenine bağlamak için kullanılır.
set_pathq, path ve query string'i tek yeniden yazma aksiyonunda yönetir. Operatör mevcut `%QUERY` değerini yeni path içine ekleyerek istemcinin gönderdiği parametreleri koruyabilir. Gerekirse query tarafına yeni parametreler de eklenebilir; örneğin `/api/v1/users?id=42` isteği `/internal/v3/users?id=42&version=v3-from-v1` biçimine dönüştürülebilir. Bu, API versiyonlama ve partner uyumluluğu için pratik bir geçiş mekanizmasıdır.
normalize_uri, path'i ve URI bileşenlerini standart forma çekmek için kullanılır. Çoklu slash birleştirme, nokta segmentlerini temizleme, `../` parçalarını çözme, güvenli karakterleri decode etme, yüzde kodlamasını büyük harfe standartlaştırma, fragment işleme ve query parametrelerini sıralama gibi seçenekler uygulanabilir. Bu normalizasyon cache anahtarı tutarlılığı, audit okunabilirliği ve güvenlik atlatma denemelerine karşı önemlidir. WAAP ve diğer güvenlik kontrollerinin aynı kanonik path üzerinde karar vermesine yardımcı olur.
STRREPLACE ilk eşleşmeyi, STRREPLACEALL ise tüm eşleşmeleri değiştirir. Operatör `%PATH.STRREPLACE("/old/", "/new/")` benzeri ifadelerle path içindeki belirli parçaları dönüştürebilir. Bu yaklaşım prefix değişimi, path ortasında segment değiştirme veya eski URL parçasını yeni servis düzenine taşıma için kullanılır. UI tarafındaki helper alanları find ve replace değerlerinin daha kontrollü girilmesini sağlar.
Her path yeniden yazma kuralı koşullu çalışabilir. Host header, HTTP metod, kaynak IP, cookie, header değeri veya FX motorunun ürettiği herhangi bir true/false ifade koşul olarak kullanılabilir. Böylece aynı vService altında partnera özel, tenant'a özel veya metod bazlı farklı path dönüşümleri kurulabilir. Eşleşmeyen istekler yeniden yazma etkisi almadan normal akışta devam eder.
set_path veya set_pathq ile istek path'i iç path'e çevrildiğinde, kurum servisi yanıt gövdesinde iç path'leri döndürebilir. modifyResponse replace modu bu iç path'leri dış path formatına geri yazar. Örneğin istemci `/api/v1/orders` ister, kurum servisi `/internal/orders` ile çalışır, yanıt JSON içindeki `"href":"/internal/users/42"` değeri `"href":"/api/v1/users/42"` olarak döner. İstemci kurum servisinin gerçek URL yapısını görmeden çalışmaya devam eder.
modifyResponse yalnızca path remap için değil, yanıt gövdesi üzerinde farklı dönüşümler için de kullanılabilir. replace modu regex veya düz metin desenlerini değiştirir ve path remap deseninin ana parçasıdır. htmlTag modu HTML etiketlerine kontrollü içerik eklemek için, mask modu ise hassas veriyi maskelemek için kullanılır. URL ve Path Düzenleme sayfasında bu yetenek özellikle çift yönlü path eşleştirme bağlamında konumlanır.
Path yeniden yazma istek aşamasında uygulanır ve sonraki güvenlik kontrolleri yeniden yazılmış path üzerinden karar verebilir. Bu davranış, virtual patching, WAAP imza eşleştirme, oran sınırlama anahtarı veya trafik kuralı gibi katmanların doğru değerle çalışmasını sağlar. Normalize edilmiş veya yeniden düzenlenmiş path, sonraki kararların ortak girdisi haline gelir. Böylece dış URL ile iç servis path'i arasındaki fark politika tutarsızlığı üretmez.
Path dönüşümü operasyonel olarak izlenebilir olmalıdır. TR7, isteğin orijinal path'ini ve yeniden yazılmış path değerini audit ve log akışına taşıyabilir. SIEM tarafında "kullanıcı hangi path'i istedi, sistem hangi path'i kurum servisine gönderdi?" sorusu cevaplanabilir. Bu görünürlük migration ve güvenlik incelemelerinde kritik önemdedir.
Aynı vService altında birden fazla path kuralı sıralı biçimde çalışabilir. İlk kural URI'yi normalize eder, ikinci kural prefix değişimi yapar, üçüncü kural query bilgisini zenginleştirir veya belirli koşulda suffix ekler. Her kural bir önceki kuralın çıktısı üzerinde çalışır. Bu model, büyük ve riskli tek kural yerine okunabilir, test edilebilir ve aşamalı dönüşüm zinciri kurulmasını sağlar.
URL path yeniden yazma; smart content değişkenleri, FX entegrasyonu, koşul dili, performans, hata davranışı ve yanıt düzenleme deseniyle birlikte işletilir.
Yeni path tanımında `%PATH`, `%QUERY`, `%HOST`, `%METHOD`, `%SRCIP`, `%PORT` ve özel değişkenler kullanılabilir. Bu değişkenler set_path ve set_pathq değer alanlarında kompoze edilerek dinamik path oluşturur. FX fonksiyonları bu değişkenler üzerinde uygulanabilir.
URL path yeniden yazma, TR7 FX ifade motorunun tüketicilerinden biridir. Operatör path dönüşümü için ayrı bir dil öğrenmez; STRREPLACE, STRREPLACEALL ve diğer FX fonksiyonlarını aynı ifade mantığında kullanır. Bu ortaklık, trafik kuralı, log şablonu ve koşul tanımlarıyla tutarlı bir yönetim modeli sağlar.
FX/ACL koşullarıyla yeniden yazma kapsamı daraltılır. `%HOST == "partner.example.com"`, `%METHOD in ["POST","PUT"]`, `%SRCIP in MAP_IP("partner_ips")` veya `%HEADER("X-Tenant") == "tenant-a"` gibi ifadeler kullanılabilir. Birden fazla koşul AND / OR mantığıyla birleştirilebilir.
Path yeniden yazma istek başına düşük ek maliyetle çalışır; string tabanlı dönüşümler ek soket veya ek dosya okuma gerektirmez. STRREPLACE ve STRREPLACEALL bellek üzerinde uygulanır. Yanıt gövdesi düzenleme daha maliyetlidir çünkü body buffer ve regex işleme gerektirebilir; bu yüzden yalnızca gerekli path remap senaryolarında kullanılmalıdır.
Yeniden yazma sırasında FX parse hatası, eksik değişken veya regex uyumsuzluğu oluşursa istek güvenli fallback davranışıyla normal akışta devam edebilir. Hata audit log'una yazılır ve operatör konfigürasyon problemini sonradan inceleyebilir. Bu yaklaşım, hatalı kuralın üretim erişimini gereksiz yere kesmesini önler.
Şeffaf path remap için önerilen desen iki parçadan oluşur: request tarafında dış path iç path'e dönüştürülür, response tarafında iç path'ler dış path'e geri yazılır. Bu iki kural aynı vService altında eşleşik çalışır. API gateway senaryoları, B2B partner entegrasyonları ve monolith-microservice geçişlerinde bu desen standart yapı olarak kullanılabilir.
Mevcut istemciler `/api/v1/...` endpoint'lerini kullanmaya devam ederken, TR7 isteği içeride `/api/v3/...` yapısına dönüştürür. Yanıt gövdesindeki v3 linkleri modifyResponse ile v1 formatına geri yazılır. İstemci kodu değişmeden modern kurum servisi devreye alınır.
Partner yıllardır `/services/payments/...` URL düzenini kullanırken iç ekip yeni `/v2/payment-api/...` yapısına geçmiş olabilir. Host koşuluyla yalnızca partner trafiğine özel set_path uygulanır. Partner eski URL ile çalışır, içeride yeni servis mimarisi kullanılır.
Eski monolith `/app/orders`, `/app/users` ve `/app/inventory` path'leriyle çalışırken, her alan ayrı kurum servisine taşınabilir. TR7 prefix bazlı yönlendirme ve path remap ile bu ayrımı istemciye göstermeden uygular. Kullanıcı aynı URL düzenini kullanırken içeride servisler ayrıştırılır.
Saldırgan encode edilmiş path, dot-segment veya slash karışıklığıyla güvenlik kontrollerini atlatmaya çalışabilir. normalize_uri path'i kanonik forma getirir ve sonraki WAAP kontrolleri bu temizlenmiş değer üzerinde çalışır. Böylece farklı yazılmış ama aynı hedefe giden URL formları daha tutarlı biçimde değerlendirilir.
API versiyonlama, B2B partner uyumluluğu ve şeffaf backend path remap — kendi servislerinizle canlı bir kurulumda gezdirelim.