Farklı API Sürümleri nasıl desteklenir

Bir Rest API yazıyorum ve farklı sürümleri desteklemeyi en iyi nasıl ele alacağımı merak ediyorum. Bununla nasıl bir URI'yi V2 veya V3 olarak tanımlayacağımı değil, kodun nasıl yapılacağını nasıl yapılandıracağımı kastediyorum:

• Aynı anda birden fazla sürümü destekleyin, örn. V1 ve V2 ve V3 URI'leri aynı anda canlı olmalıdır. Herhangi bir zamanda desteklenen miktarı sınırlamak için V4 geldiğinde V1'i emekliye ayırırım.
• Mümkün olduğunca çok kod çoğaltmasından kaçının
• Bir sürüme, diğer sürümleri etkilemeden kesintisiz değişiklikler eklemeyi kolaylaştırın

Görünebilecek birkaç yaklaşım var gibi görünüyor:

• Sürümleri, farklı sürümler için bir dalla (ve esasen üzerinde yeni geliştirme çalışmaları yapılmadan) kontrol etmek için Git'i kullanın. Bu, yalnızca en son sürüm kodda olduğu için kod çoğaltması anlamına gelmez, ancak önceki sürümlerin emekli oluncaya kadar DB'nin yeni sürümü ile çalışması gerekir.

• Her sürüm aynı uygulamada işlenecek ve tamamen ayrı bir kod yoluna sahip olacak şekilde kodu çoğaltın, ancak bu çok fazla çoğaltma anlamına gelir

• Sürümler arasında çok sayıda kod yeniden kullanın, ancak bir sürümü değiştirmenin önceki sürümü etkileme olasılığı daha yüksek olduğundan bu, bakımını zorlaştıracaktır.

Tüm seçeneklerin kendi sorunları olduğu için bu sorunla başa çıkmak için en iyi uygulama var mı?

Bunu yap:

Sürümler arasında çok sayıda kod yeniden kullanın, ancak bir sürümü değiştirmenin önceki sürümü etkileme olasılığı daha yüksek olduğundan bu, bakımını zorlaştıracaktır.

ancak önceki sürümleri bozmayın.

Desteklenen tüm sürümlerin doğru çalıştığını doğrulayan testlere sahip olmalısınız. Bu testlere sahip değilseniz, önce değiştirdiğiniz herhangi bir kodu kapsayacak şekilde bunları oluşturmanız gerekir.

Eski API sürümlerini desteklemek ve sürdürmek ve muhtemelen bir ortak kullanım kitaplığı gibi bir bağımlılık olarak paylaşılabilen bazı yeniden kullanılabilir kodlara sahip olmak için GIT sürüm dallarını (veya her sürümü ayrı bir depoya çatalla) birlikte kullanmak büyük olasılıkla yoludur gitmek. Dolayısıyla, her API sürümü ayrı olarak dağıtılabilir bir yapı olacaktır. Bu esnekliğe izin verir, örneğin API V1, müşterek V1'e bağlıyken API V2, V3, V4, müşterek V2'ye bağlı olabilir. Kod tabanınız her yeni sürümle çarpılmadığından geliştirme perspektifinden en kolay ve en temiz olurdu, bunun yerine her sürüm kendi proje / kod tabanına ayrılır ve yalnızca kendisiyle ilgilidir.

Ayrı eserler dağıtmanın bir başka nedeni, bir güvenlik mekanizması veya bağımlılık enjeksiyon çerçeveniz gibi API'nin yeni sürümlerinde değişebilecek çerçeveler / kütüphaneler gibi çapraz kesişen endişeler olabileceği ve eski API'ları desteklemede çok fazla zorluk yaratabileceğidir. hepsi aynı kod tabanında (ve Java ise çalışma zamanında Classloader'da) yaşar.

Her yaklaşımı, ister sürüm başına bir dalı, ister monolitik çoğaltılmış kod tabanı olsun, her zaman değişmesi gereken ortak bir entegrasyon noktası (DB veya dağıtılmış bir önbellek şeması gibi) sorunu olacaktır. Eski sürüm API'leri, bu değişikliklerle çalışmak için bir tür bakım gerektirebilir veya uyumluluğa yardımcı olması için diğer bazı araçların (veritabanı görünümleri gibi) kullanılmasını gerektirebilir. Bu, değişikliklerinizin niteliğine bağlı olarak kaçınılmaz bir zorluk olabilir.

Sonuçların API sürümlerinizden ne kadar farklı olduğunu bilmiyorum, ancak ortada sürümler arasında geçiş yapabilen ve boşlukları doldurabilen veya verileri çevirebilen bir uyumluluk katmanı olabilir.

Bununla birlikte, genellikle asla bire bir işe yaramaz - bu nedenle bir anahtar veya durum makine tipi tasarım bu sorunla bana yardımcı oldu.