Rest Api Versiyonlama paket yapısı?

Aşağı Git Tüm Forumlar Web Tasarım - Programlama Yazılım Geliştirme Java Rest Api Versiyonlama paket yapısı?

Bu konudaki kullanıcılar: 1 misafir, 1 mobil kullanıcı

5
Cevap 298
Tıklama 0
Öne Çıkarma

1. sayfa

Rest Api Versiyonlama paket yapısı?

Cevap Yaz

disconnectus-erectus

7 yıl

Konu Sahibi

Arkadaşlar merhaba,

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 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.

Üye Ol Şimdi Değil

Bir Daha Gösterme

funky-nd

7 yıl

Yarbay

controller
service
model
repository
config

bestanealtcizgi

7 yıl

Yüzbaşı

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.

Bu mesaja 1 cevap geldi.

disconnectus-erectus

7 yıl

Konu Sahibi

Çok Teşekkürler.

Bu mesajda bahsedilenler: @bestanealtcizgi

Mephalay

7 yıl

Yarbay

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ı > Bu mesaja 1 cevap geldi.

disconnectus-erectus

7 yıl

Konu Sahibi

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 ?

Bu mesajda bahsedilenler: @Mephalay

Cevap Yaz

1. sayfa

Tüm Forumlar Web Tasarım - Programlama Yazılım Geliştirme Java Rest Api Versiyonlama paket yapısı?