Yükleniyor...
API versioning, çoğu kurumda teknik bir detay gibi ele alınır; oysa gerçekte uzun vadeli bir sözleşmedir. Bu yazı, kurumsal sistemlerde versioning kararlarının görünmeyen maliyetlerini ve üretimde neden zorlaştığını ele alıyor.
API versioning, kurumsal mimarilerde neredeyse herkesin fikir sahibi olduğu ama çok az ekibin gerçekten yönettiği bir konudur. Toplantılarda hızla kabul edilir, dokümantasyonlara eklenir ve çoğu zaman “ileride hallederiz” varsayımıyla hayata geçirilir.
Sorun şu ki: API versioning kararları, etkisini hemen değil; aylar sonra, genellikle de beklenmeyen bir anda gösterir.
Ve o noktada geri dönüş maliyeti çok yüksektir.
Teoride versioning, API tasarımının bir parçasıdır. Pratikte ise bu, organizasyonun verdiği uzun vadeli bir sözdür.
Bir API’ye yeni bir versiyon eklediğinizde, teknik olarak sadece bir endpoint açmazsınız. Aynı zamanda şunları da kabul etmiş olursunuz:
Bu sorulara baştan cevap verilmediyse, versioning bir çözüm değil; ertelenmiş bir problemdir.
Birçok kurumda API portföyü zamanla şu hale gelir:
v1 hâlâ aktif
v2 kısmen kullanılıyor
v3 roadmap’te
Bu durum genellikle “disiplin eksikliği” olarak yorumlanır. Oysa gerçek neden daha derindedir:
Sonuçta API sayısı artar, ama kontrol artmaz.
Üretimde çalışan sistemlerde versioning kararının merkezinde şu soru olmalıdır:
Bu değişiklik gerçekten yeni bir versiyon mu gerektiriyor, yoksa mevcut davranışı kontrollü şekilde evrimleştirmek mi istiyoruz?
Örneğin:
Bu değişikliklerin çoğu, doğru yönetildiğinde yeni bir versiyon gerektirmez. Ancak bu ayrımı net yapamayan ekipler, her değişikliği v+1 ile çözmeye çalışır.
Bu da kısa sürede yönetilemez bir API yüzeyi oluşturur.
API versioning konuşulurken tartışma genellikle şu eksende döner:
Bu sorular teknik olarak önemlidir, ancak üretimde belirleyici olan bu değildir. Asıl belirleyici olan şudur:
Seçilen yöntem, organizasyonun operasyonel gerçekleriyle uyumlu mu?
Sahada gözlenen genel tablo şudur:
Burada “doğru” yöntem yoktur. Yanlış bağlamda kullanılan doğru yöntem vardır.
Versioning kararlarının gerçek maliyeti, yeni versiyon açıldığında değil; eski versiyonu kapatmaya çalıştığınızda ortaya çıkar.
O noktada şu sorular gündeme gelir:
Bu sorulara net cevap verilemiyorsa, eski versiyonlar hiçbir zaman kapanmaz. Sistem “geriye dönük uyumlu” kalmaz; donmuş hale gelir.
Başarılı ekipler, versioning’e bir numaralandırma problemi olarak değil; davranış yönetimi olarak yaklaşır.
Sahada çalışan örneklerde ortak noktalar şunlardır:
Bu yaklaşım, API’lerin kontrolsüz büyümesini engeller.
Versioning masaya geldiğinde şu sorular net şekilde sorulmalıdır:
Bu sorular cevapsızsa, versioning teknik ilerleme değil; risk üretir.
API versioning bir tasarım tercihi değil, sözleşme yönetimidir.
İyi yönetildiğinde:
Kötü yönetildiğinde ise:
Ve çoğu zaman sorun, seçilen yöntem değil; hiç konuşulmayan sonuçlardır.