Yeni Kayıt
Konudaki Resimler
|
Hızlı 
Bildirim
Rest Api Versiyonlama paket yapısı?
Sıcak Fırsatlarda Tıklananlar
Editörün Seçtiği Fırsatlar
Daha Fazla 
Bu Konudaki Kullanıcılar:
Daha Az 
2 Misafir - 2 Masaüstü
Giriş
Mesaj
-
-
controller
service
model
repository
config -
Merhaba,
Rest api versiyonlamasi icin pek cok farkli gorus var, kesin dogru diye bir kavram yok. Sizin projeniz icin hangisi uygunsa onu kullanmak daha uygun olur.
Oncelikle, endpoint lerinizin versiyonlamasini nasil yapmak istediginize karar vermeniz gerekiyor. Varsayalim ki urunleri listeleyen /products diye bir endpointiniz var. Oldu da yeni versiyon cikarmaniz gerekti, farkli versiyonlari cagirmak icin farkli url yaratabilirsiniz /products/${version} gibi. Bu durumda /products/v1, products/v2 gibi path parametresi uzerinden farkli versiyonlar cagirilabilir. Bu url parametresi de olabilir tabi. Bir diger alternatif de request header'da versiyon bilgisi gondermek.
Fakrli versiyonlari gonderdiginiz semadaki gibi farkli controller lar icerisinde tutmak zorunda degilsiniz. Hatta bu biraz daginiz bir yapiya da yol acabilir. Farkli paketlerde farkli controller'da birbirine benzer url'ler ortaya cikacaktir. Bu yuzden butun endpointleri tek controller icerisinde tutmak yonetebilmek icin daha uygun olacaktir. Kullanilmasini istedmediginiz eski versiyonalari once @deprecated ile etiketlersiniz daha sonra da kullanim tamamen ortadan kalkinca silersiniz, parametreler ve donus tipleri ayni ise yeni versiyona yonelndirebilirsiniz vs.
Farkli versiyona sahip endpointler icin farkli implementasyonlar cagirmak daha uygun. /products/v1 icin farkli, /products/v2 icin farkli converter implementasyonu cagirirsiniz.
Kisaca, rest api ya da herhangi bir api icin farkli versiyonlari farkli paketlerde tutmak projeyi kontral altinda tutmayi zorlastirabilir. En genel gecer yaklasim, butun endpointler ayni yerde olsun, eski endpointler mumkunse yenisine yonelendirsin ve eski versiyonu depracated yapip kullanimi sona erdikten sonra silmek yonunde.
-
bestanealtcizgi
B
kullanıcısına yanıt
Çok Teşekkürler. -
Her versiyon icin farkli paket olmaz. Versiyon bigisini GET URL inde ya da POST icerisinde data object'inde icerip, Adapter ya da Decorator pattern i kullanarak karsilamak gerekiyor.
MusteriBilgisiV1 implements MusteriBilgisi --> Response objesi v1
MusteriBilgisiV2 implements MusteriBilgisi ---> Response objesi v2
MusteriBilgisi getMusteriBilgisi ( hede, hodo ) ---> Controller , versiyona gore farkli implementasyon cagiriyor return type yine ayni interface versiyondan bagimsiz.
MusteriManager ---> Farkli implementasyonu implemente eden business logic iceren class
Bunun gibi. Yine controller, service, DAO, manager , model paketleri icerisinde dagilacak. Adapte eden ya da dekore eden class Manager olacak. Controller seviyesinde business logic implemente edilmemeli.
Eger SDK publish edeceksen de JavaDoc ile degisen parametreleri vs dokumante etmek gerekiyor.
< Bu ileti tablet sürüm kullanılarak atıldı > -
Mephalay
M
kullanıcısına yanıt
Anladım sanırım, versiyonları yönetmek için manager sınıfları olucak, controllerda bunlar araclığı ile implementasyon çağıracağız.
Bu tarz bir yapı için, inceliyebileceğim open source bir proje var mıdır acaba ?
Sayfa:
1
Ip işlemleri
Bu mesaj IP'si ile atılan mesajları ara Bu kullanıcının son IP'si ile atılan mesajları ara Bu mesaj IP'si ile kullanıcı ara Bu kullanıcının son IP'si ile kullanıcı ara
KAPAT X
Bu mesaj IP'si ile atılan mesajları ara Bu kullanıcının son IP'si ile atılan mesajları ara Bu mesaj IP'si ile kullanıcı ara Bu kullanıcının son IP'si ile kullanıcı ara
KAPAT X
