Rest api yapı tartışması

Forumda kod paylaşılırken dikkat edilmesi gerekenler!Birlikte proje geliştirmek ister misiniz?

Rest api yapı tartışması

deathisonitsway

Sevgili dostlar; Bazen bu konu tartışmalara neden oluyor.Herkesin yoğurt yemesi sonuçta bir şey denemez;

Düşünce olarak şöyle başlayayım.Mobil işler yapıyoruz ve restfull sistemler backendin ayrılmaz parçaları oluyor.
Hal böyle olunca akla şöyle bir şey geliyor.İyide versiyonlamanın amacı nedir?

Kişisel fikrim hala bunu bildiğimizi sanmıyorum?

Benim en net düşüncem şudur; Her versiyonlama applicationun tümünü beraberinde götürmelidir.

Amacım şu ;

V1/

Controller
Model
Migration
Middleware
Repository

yapısal olarak versiyonlamaya göre değişebilecek modüller versiyonlamanın içinde olmalıdır.

Ancak böyle yapmaktan ziyade; bu bir disk canavarı olabilir.Versiyonlamada değişmeyecek modüllerde her versiyonlama ile boşuna taşınmış olur fikriyatı hasıl olmuyor değil.

Ancak bu türün de dezavantjı yok değil.Ornegin versiyon 5 e gelinmiş ama hangi modülün güncel olduğunu tespit etmekte zorlaşabilir.

Bu konu için görüşlerinizi alabilir miyim? benim için çok değerli olacaktır.

alihankoc

Ben rotalarda ayırıyorum.

V1/

Controller
Model
Migration
Middleware
Repository

v1 için tüm dizinler var.

diyelim ki v2 ye geçtik ve sadece user controller da değişiklik yaptık.

V2/
Controller
 -User Controller

V2 klasöründe sadece onu oluşturuyorum.
Sonra rotada örnek şöyle yapıyorum.

Route::get('posts', 'V1\PostController@get');
Route::get('users', 'V2\UserController@get');

V2 de yeni güncelleme oldukça sadece gerekli dosyaları yeni dizinde oluşturup rotadan değiştiriyorum. Böylece aynı dosyalar kopyalanmıyor hiçbir zaman.
Rotalarda namespace ile de v1 ve v2 rotalarını rahatlıkla ayırabiliyorum. V1 den V2 ye rotayı taşımak yetiyor.

deathisonitsway

öyle de olurda ; ben onu çok sevemedim bir türlü.hangi service nerde karışıyor gibime geliyor.ben laravelde route okuma taraftarıda değilim açıkcası.o rota dosyası şişiyorda şişiyor..

evrend

Web servislerdeki versiyonlamanın asıl amacı; Şirket dışı son kullanıcıların kullanacağı, 3. parti uygulamalarla entegre olması planlanan web servislerde(nvi, facebook, twitter, aws, digitalocean vs. vs.), serviste yapılan değişikliklerin binlerce, duruma göre milyonlarca kişi tarafından bir yerlerde kullanılmış olmasıdır. Dolayısıyla yapılan en ufak bir değişiklik herkesin çalışan sistemini etkileyeceğinden, farklı bir endpoint(v2, v3)'ten servislerin yeni halleri sunulur.
Eğer servisi son kullanıcılar kullanmayacaksa; Yani sadece bir mobil uygulamada kullanacaksanız, serviste versiyonlama yapmak çok da gerekli değildir. Hatta web servisin getirdiği bence en büyük avatajı ortadan kaldırmış olursunuz. Web servislerin en büyük avantajlarından biri olarak gördüğüm; uygulamanın kaynak koduna el sürmeden, web servis üzerinden uygulamanın mantıksal/logic kısmında güncellemeler yapılabilmesidir. Ama versiyonlama olduğunda kaynak kod çoğu senaryoda değişecektir. Ayrıca v2'si çıkan her endpoint ve kodu boşa çıkacaktır.
Sonuç olarak sadece mobil uygulama için kullanılacak bir rest apinin versiyonlamasına gerek olmadığını düşünüyorum. Git'teki versiyonlama zaten geriye dönük kodlarınızı tüm detayları ile versiyonluyor. Kullanmayacağınız kodların, projede kalması da bana doğru gelmiyor.

alihankoc

@evrend katılıyorum, tek bir servis için yapılıyorsa versiyonlama çok fazla gerekli değil, v2 yayına geçtiğinde hala v1 i kullanan biri yoksa neden v2 ile v1 diye bölelim ki doğrudan güncelleştiririz. Ama belki ileride başka servisler de kullanabilir düşüncesiyle yaptığını varsayalım.

truematch wrote:öyle de olurda ; ben onu çok sevemedim bir türlü.hangi service nerde karışıyor gibime geliyor.ben laravelde route okuma taraftarıda değilim açıkcası.o rota dosyası şişiyorda şişiyor..

Benim fikrime göre; rota dosyaları ayrılabilir, ki yine öyle olmalıdır. routes/v1.php, routes/v2.php gibi mantıklı isimlerle parçalara ayırmak her türlü rahatlığı sağlar. Servislerin yerlerinin karışması derken tam olarak ne dediğinizi anlayamadım ama bir api yapılıyorsa birşeylerin karışmaması için bir dökümantasyonu olmalıdır. Böylece ne nereden çalışıyor diye düşünmeye gerek kalmaz.

mgsmus

Ben her versiyonun bir öncekinden bağımsız olarak çalışabilmesinden yanayım. v1 v2'yi; v2 de v1'i etkilememeli. Sonuçta v2 varken v1'in kullanılmaya devam edilme durumu olabilir ve v1 üzerinde güncelleştirme yapılabilir. v1 ayrı bir yere taşınabilir vs... truematch'in bahsettiği "Boşuna taşınmış fikriyatı" gibi bir şeyi de düşünmem açıkçası. Bu yıllar önceki vendor tartışması gibi bir şey. O zamanlar vendor klasörü niye bu kadar büyük, kullanmadığım paketleri nasıl silerim gibi sorular çoktu, şimdi kimse içine girip paketlere ya da boyutuna bakmıyor.

Modül güncelliği tespiti gibi konular için de versiyon kontrolünün yeterli olacağını düşünüyorum.

Ayrıca url içerisinde v1, v2... barındırmadan da query string, header ya da json-rpc 2.0 kullanarak da tek bir endpoint ile versiyonlama içeride yapılacak şekilde iş götürülebilir. Bunu Api'nin boyutu, güncellenme sıklığı, eski/yeni versiyon kullanım oranları... gibi noktalar (ya da belki de kişisel zevkler) belirleyecektir sanırım.

deathisonitsway

mgsmus gibi düşünenlerdenin ve bu düşüncede olan communityde çok kişi var.Yani major bir versiyon değişikliğinde applicationun tümü hareket etmelidir..bunun fazladan diskte yer kaplaması olayına cok takılmamak lazım diye dusunuyorum.Zira cok buyuk dosyalar değil yazılan kodlar.Bir bütünlük arz etmeli diye düşünüyorum.Laravelde bu şekil bir rest api kurgum var ancak istediğim gibi esnek tutmuyor beni laravel.O yüzden rotaya versiyonlamayı alihankoc un yaptıgı gibi yapmak benim hoşuma gitmeyen kısım.ikide birde acıp rotada ne var diye okumak beni sıkıyor açıkcası..standarda oturtmak lazım bu işleri..

Birde eloquent sparsefield olayına destek getirse hiç fena olmaz diye düşünüyorum.

Laravel Türkiye Forumları, ücretsiz forum uygulaması Flarum ile yapılmıştır.