Versiyonlu bir yapıda REST API geliştirmek istiyorum.
Fakat paketleri tam olarak nasıl ayırmam gerektiğini bilmiyorum, Versiyon ile birlikte değişen kısımların controller'daki pathler, DTO objeleri ve bu DTO objeler için tanımlı converterlar olduğunu düşünerek aşağıdaki gibi bir paket yapısı oluşturmaya karar verdim.
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.
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.
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.
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 ?
Versiyonlu bir yapıda REST API geliştirmek istiyorum.
Fakat paketleri tam olarak nasıl ayırmam gerektiğini bilmiyorum, Versiyon ile birlikte değişen kısımların controller'daki pathler, DTO objeleri ve bu DTO objeler için tanımlı converterlar olduğunu düşünerek aşağıdaki gibi bir paket yapısı oluşturmaya karar verdim.
├── api
│ ├── v1
│ │ ├── controller
│ │ ├── converter
│ │ └── dto
│ │
│ └── v2
│ ├── controller
│ ├── converter
│ └── dto
│
├── domain
├── repository
├── config
├── validator
├── exception
└── service
bu yapı mantıklı mıdır?
Genelde API versiyonlamak için nasıl bir paket yapısı kullanılmalıdır? tecrübeli olan arkadaşlar yardımcı olursa sevinirim.
DH forumlarında vakit geçirmekten keyif alıyor gibisin ancak giriş yapmadığını görüyoruz.
Üye Ol Şimdi DeğilÜye olduğunda özel mesaj gönderebilir, beğendiğin konuları favorilerine ekleyip takibe alabilir ve daha önce gezdiğin konulara hızlıca erişebilirsin.