Arka ucunuzu bir API olarak mı yazmalısınız?

Bugün MVC uygulamamızla ilgili ateşli bir tartışma yaptım. MVC'de ( ASP.NET ) yazılmış bir web sitemiz var ve genellikle görünümde bir şeyler yapmanın modelini izliyor -> denetleyiciye isabet et -> denetleyici bir model oluşturur (veri alan bir Yöneticisi çağırır, modeli oluşturur. denetleyici yönteminin kendisi) -> model görüntülemeye gider -> durulama ve tekrarlama.

Kurallarımızın çok sıkı bir şekilde bağlı olduğunu söyledi. Örneğin, bir masaüstü uygulamasını da istersek, mevcut kodumuzu kullanamazdık.

Söylediği çözüm ve en iyi uygulama, bir API oluşturmak ve ardından web sitenizi API'nizin üzerine koymak ve ardından bir masaüstü uygulaması, mobil uygulama vb. Oluşturmak çok basittir.

Bu, çeşitli nedenlerden dolayı bana kötü bir fikir gibi görünüyor.

Her neyse, bu uygulamayı tartışabilecek googling ile bir şey bulamıyorum. Artıları, eksileri, neden olmasın, neden olmasın ya da daha fazla okumalısın?

Bazı nedenlerin kötü bir fikir olduğunu düşünüyorum:

• Arka ucunuzu bir API'den çıkarmak çok soyut. Yönetilemez bir karışıklık yaratacak kadar esnek hale getirmeye çalışıyorsunuz.

• MVC'ye yerleştirilen her şey, roller ve kimlik doğrulama gibi, işe yaramaz görünüyor. Örneğin, [Yetki] özellikleri ve güvenlik; kendin yapmalısın.

• Tüm API çağrılarınız ekli güvenlik bilgileri gerektirecek ve bir simge sistemi geliştirmek zorunda kalacaksınız.

• Programınızın yapacağı her işlev için eksiksiz API çağrıları yazmanız gerekecek. Hemen hemen uygulamak istediğiniz her yöntemin bir API dışında bırakılması gerekir. Her kullanıcı için bir Al / Güncelle / Sil, artı her diğer işlem için bir değişken, örneğin kullanıcı adını güncelle, bir gruba kullanıcı ekle, vb. Ve her biri ayrı bir API araması olacaktır.

• API'ler söz konusu olduğunda, arayüzler ve soyut sınıflar gibi her türlü aracı kaybedersiniz. WCF gibi şeyler arayüzler için çok hassas bir desteğe sahiptir.

• Bir kullanıcı oluşturan veya bazı görevleri gerçekleştiren bir yönteminiz var. 50 kullanıcı oluşturmak istiyorsanız, onu 50 kez arayabilirsiniz. Bu yöntemi bir API olarak yapmaya karar verdiğinizde, yerel web sunucunuz boruları bağlayabilir ve hiçbir sorunla karşılaşmaz - masaüstü istemciniz de buna isabet edebilir, ancak birdenbire toplu kullanıcı oluşturma işleminiz, API’yi İnternet’te 50 kez kırmayı gerektirir. iyi değil. Bu nedenle toplu bir yöntem oluşturmanız gerekir, ancak gerçekten sadece masaüstü istemcileri için oluşturuyorsunuz. Bu yolla, a) API'nızı, onunla entegre olana dayanarak değiştirmek ve doğrudan onunla bütünleştirmek mümkün değildir, b) fazladan bir işlev oluşturmak için çok daha fazla iş yapın.

• YAGNI . Özellikle aynı işleyen iki uygulamayı, örneğin bir web ve bir Windows uygulamasını yazmayı planlamıyorsanız, bu büyük miktarda ekstra geliştirme çalışmasıdır.

• Baştan sona adım atamadığınız zaman hata ayıklama çok daha zordur.

• Örneğin, bazı kodlar geçerli kullanıcıyı alabilir, kullanıcının yönetici rolünde olup olmadığını kontrol edebilir, kullanıcının ait olduğu şirketi, diğer üyelerin listesini alabilir, hepsini gönderebilir. bir e-posta. Bu çok fazla API çağrısı gerektirebilir veya ısmarlama bir yöntemle istediğiniz belirli görevi yazabilir; ısmarlama yöntemin tek yararı hız olacaktır, ancak olumsuz tarafı ise esnek olamazdı.

• Muhtemelen bunların birçoğunun kafamın üstünde olmasına neden olan başka sebepler de var.

Sadece iki özdeş uygulamaya ihtiyaç duymadığınız sürece bana öyle geliyor, o zaman buna gerçekten değmez. Ben de böyle bir ASP.NET uygulaması görmedim, iki ayrı uygulama yazmanız (API ve kodunuz) ve sürümün her ikisini de kontrol etmeniz gerekir (kullanıcı sayfanız yeni bir alan alırsa, siz d Etkileyici olmamasını sağlamak için API ve tüketim kodunuzu aynı anda güncellemeniz veya sağlam kılmak için fazladan fazla çalışma yapmanız gerekir).

Düzenleme: Gerçekten tüm bunların ne anlama geldiğiyle ilgili iyi bir fikir edinmeye başlayan bazı büyük tepkiler. Öyleyse sorumu genişletmek için, bu API yapısını takip edecek bir MVC uygulamasını nasıl yapılandırırsınız?

Örneğin, bir kullanıcı hakkında bilgi görüntüleyen bir web siteniz var. MVC’de aşağıdakilere sahipsiniz:

Görünüm - (CS) Bir UserViewModel Denetleyicisini görüntüleyen HTML sayfası - GetUser () işlevini çağırır ve bir GetUser yöntemine sahip olan görünüm Yöneticisi sınıfına (API'nizin türünü) ileten bir UserViewModel oluşturur.

Denetleyici GetUser () işlevini kullanır, ancak siz de bir masaüstü uygulaması istiyorsunuz. Bu, GetUser'ınızın bir çeşit API aracılığıyla gösterilmesi gerektiği anlamına gelir. TCP bağlantısı, WCF veya belki de Uzaktan Kumanda'yı isteyebilirsiniz. Ayrıca kalıcı bağlantılar lapa lapa olduğu için RESTful olacak bir mobil uygulama da istiyorsunuz.

Öyleyse her biri için bir API, GetUser () metoduna sahip bir WCF web servisi ve kodun aynısını yazacak mısın return new UserManager().GetUser()? Ve aynı şeyi yapan bir mvc 4 web api yöntemi? MVC denetleyici yönteminizde GetUser'ı doğrudan aramaya devam ederken mi?

Veya üçünün de (web api REST servisi) işe yarayacak çözümü seçip bunun üzerine her şeyi inşa edersiniz, böylece üç uygulama da API çağrıları yapar (mvc olanlar, yerel makineye).

Ve bu sadece teorik mükemmel bir senaryo mu? Bu yolun geliştirilmesinde büyük genel giderler görebiliyorum, özellikle de işlemlerinizi RESTful olarak yapmanıza izin verecek şekilde geliştirmek zorundaysanız. Bunun bir kısmının cevaplarda ele alındığını düşünüyorum.

Düzenleme 2: Daha fazla şey okuduktan sonra, aşağıda açıklayabileceğimi düşündüğüm bir yorum yaptım. Soru, sanırım biraz hileli bir soru. Bir API olarak arka uçunuzu yazmanız durumunda kafam karıştı, her şeyin (mvc uygulaması, masaüstü uygulaması, mobil uygulaması) bir şeyler yapmak için çağırdığı tek bir web hizmeti olması gerektiğini düşünüyorum.

Geldiğim sonuç, gerçekten yapmanız gereken şeyin iş mantığı katmanınızın doğru bir şekilde ayrıldığından emin olmak olduğu. Koduma bakarken, bunu zaten yapıyorum - denetleyici GetUser()bir yöneticiyi arayacak ve daha sonra bir Görünüm ile işlemek için bir görünüm modeli oluşturacaktır. Yani gerçekten, iş mantığı katmanı olan bir API. Ancak bir masaüstü uygulamasından aramak istiyorsanız, aramayı kolaylaştırmak için bir WCF servisi gibi bir şey yazmanız gerekir. Sadece GetUser()kodu içeren denilen bir WCF yöntemine sahip olmak bile return MyBusinessLayer.GetUser()yeterli olacaktır. Bu yüzden API, iş mantığıdır ve WCF / web api vb. Harici uygulamaların çağırmasına izin veren kodun sadece bir kısmıdır.

Dolayısıyla, bazı ek yükler vardır, ihtiyaç duyduğunuza bağlı olarak iş mantığı katmanınızı farklı API'lere sarmanız ve diğer uygulamalarınızın yapmasını istediğiniz her işlem için bir API yöntemi yazmanız gerekecek, artı yapmanız gerekecek. kimlik doğrulama yapmak için bir yol ayırın, ancak çoğunlukla aynıdır. İş mantığınızı ayrı bir projeye dahil edin (sınıf kütüphanesi) ve muhtemelen sorun yaşamayacaksınız!

Umarım bu yorum doğrudur. Ürettiği tüm tartışma / yorumlar için teşekkür ederiz.

Evet yapmalısın.

Yalnızca arka ucunuzu yeniden kullanılabilir kılmakla kalmaz, daha fazla güvenlik ve daha iyi tasarım sağlar. Arka ucunuzu tek bir sistemin bir parçası olarak yazarsanız, genişletilmesi, değiştirilmesi veya geliştirilmesi hiç kolay olmayan monolitik bir tasarım yapıyorsunuz.

Bunun şu anda popüler olduğu alanlardan biri, Microservices . Arka uçta, her biri istemci sisteminin kullandığı bir API sağlayan birçok küçük (ya da hatta büyük) hizmete ayrılır. Başvurunuzda birçok 3. taraf veri kaynağı kullanmayı düşünüyorsanız, bunu zaten yapıyor olabilirsiniz.

Diğer bir yararı, her bir hizmetin yapım ve bakımının farklı bir takıma devredilmesi, buna ek olarak herhangi bir ekibi üreten ürünü etkilemeyen özellikler eklemesidir. Sadece onlar bittiğinde ve hizmetlerini bıraktıklarında, tüketmek için ürününüze özellikler eklemeye başlarsınız. Bu, gelişimi daha pürüzsüz hale getirebilir (genel olarak potansiyel olarak daha yavaş olsa da, daha iyi kalite ve anlaşılabilir olma eğiliminde olursunuz)

Düzenleme: Tamam, sorununuzu görüyorum. API'yi uzak bir kütüphane olarak düşünüyorsunuz. Değil. Hizmeti bir veri sağlama hizmeti olarak düşünün. Veri almak için servisi arayın ve ardından yerel olarak bu veriler üzerinde işlemler yapın. Bir kullanıcının oturum açıp açmadığını belirlemek için " GetUser" numaralı telefonu arayacak ve ardından 'logged on'değere bakacaksınız. ( Tabii ki bu örnekte YMMV ).

Toplu kullanıcı yaratma konusundaki örneğiniz sadece mazeret yaratıyor - burada hiçbir fark yok, monolitik bir sistemde yapabilecekleriniz hala bir hizmet mimarisinde yapılabilir (örneğin, toplu olarak oluşturmak için bir dizi kullanıcıyı geçtiniz veya oluşturmak için tek bir tane. Servisler ile aynısını yapabilirsiniz.

MVC zaten izole edilmiş hizmetler kavramına dayanıyor, sadece MVC çerçeveleri bunları tek bir projeye yerleştiriyor. Bu, çerçevenin size verdiği paketlenmiş yardımcılar dışında herhangi bir şey kaybettiğiniz anlamına gelmez. Farklı bir çerçeve kullanın ve farklı yardımcıları kullanmanız gerekir. Veya, bu durumda, kendinizinkini almak (veya doğrudan bir kütüphane kullanarak bunları eklemek).

Hata ayıklama da kolaydır - API'yi yalıtılmış bir şekilde ayrıntılı bir şekilde test edebilirsiniz, böylece içine hata ayıklamak zorunda kalmazsınız (ve uçtan uca hata ayıklayabilirsiniz, Visual Studio aynı anda birkaç işleme ekleyebilir).

Ek iş güvenliği sağlama gibi şeyler iyi bir şeydir. Şu anda, tüm kodu web sitenize eklerseniz, bir bilgisayar korsanı ona erişirse, ayrıca DB dahil olmak üzere her şeye erişirler. Bir API'ye bölerseniz, hacker da API katmanını hacklemedikçe kodunuzla çok az şey yapabilir - ki bu onlar için inanılmaz zor olacak (saldırganların tüm web sitelerinin kullanıcılarının veya cc ayrıntılarının geniş listelerini nasıl elde ettiklerini hiç merak ettiniz mi? işletim sistemini veya web sunucusunu hacklediler ve DB ile doğrudan " select * from users" kolaylıkla çalıştırabilecekleri bir bağlantıya sahipti .

Bunun gibi yazılmış birçok web sitesi (ve istemci-sunucu uygulamaları) gördüğümü söyleyeceğim. Finansal hizmetler endüstrisinde çalıştığımda, hiç kimse bir web sitesi yazmamış, kısmen de bir güvenlik riski olduğu için ve kısmen de çoğu geliştirme istikrarlı (yani eski) arka uç veri işleme konusunda oldukça GUI olduğundan sistemleri. DP sistemini hizmet tarzı mimarisini kullanarak bir web sitesi olarak ortaya çıkarmak kolaydır.

2. Düzenleme: Konuyla ilgili bazı bağlantılar (OP için):

Bunlar hakkında bir web sitesi bağlamında konuşurken, web sunucusunun, diğer katmanları çağıran istemci olduğu ve ayrıca görüntülenmesi için tarayıcıya gönderilen UI görünümlerini oluşturduğu için sunum katmanı olarak görülmesi gerektiğini unutmayın. Bu büyük bir konudur ve uygulamanızı tasarlamanın birçok yolu vardır - veri merkezli veya etki alanı merkezli (Genelde etki alanını 'daha saf', ancak YMMV olarak etki alanı merkezli buluyorum ), ancak hepsi arasında bir mantıksal katman yapıştırarak ortaya çıkıyor Müşteriniz ve DB'niz. Ortanca, API, Modelinize eşdeğer olduğunu düşünüyorsanız, MVC'ye biraz benziyor, yalnızca model DB için basit bir sarıcı değil, daha zengin ve çok daha fazlasını yapabilir (örneğin, 2 veri kaynağından toplam veri - API’ye uygun verileri işle, verileri önbelleğe al, vb.):

• Çok katmanlı mimari
• .NET'te N Katmanlı Bir Uygulama Oluşturma
• Youtube eğitimi - C # 'da uygulanacak olanı da dahil olmak üzere ilgili bağlantıları da görün
• Çoğul görüş eğitim kursu (ücretsiz deneme veya ücretli)

Bir API oluşturmaktan muhtemelen kaçınamazsınız . "Sadece bir Web sitesi" oluştursanız bile, verilerini yine de arka uçtan almanız gerekecek. Ancak bunu yapmaya karar verirseniz, bu sizin fiili API'nızdır.

Bunu bilerek, asıl soru bir API oluşturup oluşturmayacağı değil, nasıl oluşturulacağı değildir . Anında bir geçici iş olarak bunu gerçekleştirebilirsiniz - ve gerçekten de, pek çok Web sitesi tam olarak bu şekilde inşa edilmiştir - veya başka bağlamlarda kullanılabilir olması için dikkatlice tasarlayabilirsiniz. Bu bağlamda, iş arkadaşınızın haklı olduğu açıkça anlaşılır: önce API'yi yapmalı ve ardından sitenizi bunun üzerine oluşturmalısınız.

Bununla birlikte, bu sizin de belirttiğiniz gibi bazı endişeleri beraberinde getirmektedir. Onları ele almak için:

Arka ucunuzu bir API'den çıkarmak çok soyut. Yönetilemez bir karışıklık yaratacak kadar esnek hale getirmeye çalışıyorsunuz.

Bu nasıl yaptığınıza bağlı. As George Polya onun mükemmel metinde işaret çözme It nasıl , çoğu zaman "daha genel sorun çözmek daha kolay olabilir". Buna Mucit Paradoksu denir . Programlama durumunda, genellikle endişelerin ayrılması yoluyla çalışır: arka ucunuz artık içine koyduğu ve çıkardığı verinin formatı ile ilgilenmek zorunda değildir ve bu nedenle kodu çok daha basit olabilir. Veri ayrıştırıcılarınız ve oluşturucularınızın artık oluşturdukları verilere ne olacağıyla ilgilenmeleri gerekmez, böylece onlar da daha basit olabilir. Hepsi kodu daha kolay yönetilebilir parçalara ayırarak çalışır.

MVC'ye yerleştirilen her şey, roller ve kimlik doğrulama gibi, işe yaramaz görünüyor. Örneğin, [Yetki] özellikleri ve güvenlik; kendin yapmalısın.

Araçlarını öğrenmeyi reddeden insanlara sempati duymanın son derece zor olduğunu itiraf ediyorum. Sırf onların kullanımlarını anlamamanız, onların yararsız oldukları anlamına gelmez ve kesinlikle kendi kullanımınızı atmanız gerektiği anlamına gelmez . Aksine; Alternatifleri anlayana kadar kendi araçlarınızı kullanmamalısınız , böylece yaptıkları aynı problemleri (sadece kendi yolunuzda olsa bile) ele alacağınızdan emin olabilirsiniz.

Linux yazması en meşhur olan fakat git yazan Linus Torvalds'ı düşünün : şimdi dünyanın en popüler versiyon kontrol sistemlerinden biri. Tasarımındaki itici faktörlerden biri, Subversion'a karşı derin bir muhalefetti (bir diğer son derece popüler VCS ve tartışıldığı zaman gitmenin en popüler olanı); Subversion'un alabileceği her şeyi almaya karar verdi ve mümkün olduğu ölçüde bu sorunları farklı şekilde çözdü. Bunu yapmak için , tam olarak aynı problem alanlarını anlayabilmesi ve farklı bir yaklaşım alabilmesi için Subversion konusunda kendi başına bir uzman olması gerekiyordu.

Veya araçlarınızı öğrenme sürecinde kendinizi olduğu gibi yararlı olduklarını ve değiştirilmeleri gerekmediğini bulabilirsiniz.

Tüm API çağrılarınız ekli güvenlik bilgileri gerektirecek ve bir simge sistemi geliştirmek zorunda kalacaksınız.

Evet. Olması gereken bu.

Programınızın yapacağı her işlev için eksiksiz API çağrıları yazmanız gerekecek. Hemen hemen uygulamak istediğiniz her yöntemin bir API dışında bırakılması gerekir. Her kullanıcı için bir Al / Güncelle / Sil, artı her diğer işlem için bir değişken, örneğin kullanıcı adını güncelle, bir gruba kullanıcı ekle, vb. Ve her biri ayrı bir API araması olacaktır.

Şart değil. Burası REST gibi mimarilerin devreye girdiği yer. Uygulamanızın birlikte çalıştığı kaynakları ve bu kaynaklara uygulanması anlamlı olan işlemleri belirlersiniz ve daha sonra bunları diğerleri hakkında endişelenmeden uygularsınız .

API'ler söz konusu olduğunda, arayüzler ve soyut sınıflar gibi her türlü aracı kaybedersiniz. WCF gibi şeyler arayüzler için çok hassas bir desteğe sahiptir.

Aksine, bir API kullanırken daha az değil , arayüzler çok daha önemli hale gelir . Onları oluşturduğunuz temsillerde ortaya çıkarlar. Günümüzde çoğu insan bunun için JSON tabanlı bir format belirlemektedir , ancak iyi belirttiğiniz sürece istediğiniz herhangi bir formatı kullanabilirsiniz. Çağrılarınızın çıktısını arka uçtaki bu formata dönüştürür ve ön uçta istediğiniz şeyi (muhtemelen aynı türdeki nesneler) ayrıştırırsınız. Genel gider küçük ve esneklikteki kazanımlar çok büyük.

Bir kullanıcı oluşturan veya bazı görevleri gerçekleştiren bir yönteminiz var. 50 kullanıcı oluşturmak istiyorsanız, onu 50 kez arayabilirsiniz. Bu yöntemi bir API olarak yapmaya karar verdiğinizde, yerel web sunucunuz boruları bağlayabilir ve hiçbir sorunla karşılaşmaz - masaüstü istemciniz de buna isabet edebilir, ancak birdenbire toplu kullanıcı oluşturma işleminiz, API’yi İnternet’te 50 kez kırmayı gerektirir. iyi değil. Bu nedenle toplu bir yöntem oluşturmanız gerekir, ancak gerçekten sadece masaüstü istemcileri için oluşturuyorsunuz. Bu yolla, a) API'nızı, onunla entegre olana dayanarak değiştirmek ve doğrudan onunla bütünleştirmek mümkün değildir, b) fazladan bir işlev oluşturmak için çok daha fazla iş yapın.

Mevcut bir yöntemin toplu bir versiyonunu oluşturmak "çok daha fazla iş" olarak adlandırdığım bir şey değil. Atomiklik gibi şeyler hakkında endişelenmiyorsanız, toplu yöntem, orijinal için çok ince bir ön uçtan çok daha fazlası olamaz.

YAGNI . Özellikle aynı işleyen iki uygulamayı, örneğin bir web ve bir Windows uygulamasını yazmayı planlamıyorsanız, bu büyük miktarda ekstra geliştirme çalışmasıdır.

Hayır, YANI (Zaten İhtiyacınız Var). Bunu yukarıda açıkladım. Tek soru, tasarımın içine koymak için ne kadar çalıştığını.

Baştan sona adım atamadığınız zaman hata ayıklama çok daha zordur.

Neden uçtan uca adım atmak istemiyorsun?

Ancak, daha da önemlisi, tüm ekran hamlesini ortadan kaldıran ve kolayca tanınan bir formatta ileri geri giden verileri inceleyebilmek, aslında hata ayıklamayı daha zor değil, daha kolay hale getirme eğilimindedir .

Örneğin, bazı kodlar geçerli kullanıcıyı alabilir, kullanıcının yönetici rolünde olup olmadığını kontrol edebilir, kullanıcının ait olduğu şirketi, diğer üyelerin listesini alabilir, hepsini gönderebilir. bir e-posta. Bu çok fazla API çağrısı gerektirebilir veya ısmarlama bir yöntemle istediğiniz belirli görevi yazabilir; ısmarlama yöntemin tek yararı hız olacaktır, ancak olumsuz tarafı ise esnek olamazdı.

REST bunu , nesnelerin bireysel özelliklerinden ziyade tam nesneler ( REST teorisinin terimlerini kullanmak için kaynaklar) üzerinde çalışarak çözer . Bir kullanıcının adını güncellemek için, kullanıcı nesnesini ALIN, adını değiştirin ve kullanıcıyı geri bırakın. Kullanıcı adını da değiştirirken aynı anda başka değişiklikler de yapabilirsiniz. Daha genel bir problemin çözülmesi daha kolay hale gelir, çünkü bir nesnenin bireysel özelliklerini güncellemek için tüm bu bireysel çağrıları ortadan kaldırabilirsiniz: sadece yükleyin ve kaydedin.

Bazı yönlerden, bu donanım tarafındaki RISC mimarilerine benzemez . RISC ve CISC (selefi) arasındaki temel farklardan biri, CISC mimarilerinin doğrudan belleğe işleyen birçok talimatı içerme eğilimi göstermesidir; RISC mimarileri ise çoğunlukla kayıtlarda çalışma eğilimindedir: yalnızca RISC mimarisinde, bellekteki tek işlem LOAD (bellekten bir sicile bir şey kopyala) ve STORE (sicilden bir değer al ve belleğe koy).

Bunun makineyi yavaşlatan kayıtlardan hafızaya daha fazla yolculuk yapmak anlamına geleceğini düşünürdünüz. Ancak pratikte bunun tam tersi olur: işlemci (istemci) hafızaya (sunucuya) yapılan geziler arasında daha fazla iş yapar ve bu hızlanmanın geldiği yer burasıdır.

Uzun lafın kısası: meslektaşın haklı. Bu gitmek için yol. Biraz ön çalışmaları karşılığında, o ölçüde Web Sitesi için kod basitleştirecek ve diğer web siteleri ve uygulamalar ile daha iyi entegrasyon sağlar. Bu ödemeye değer bir bedel.

Daha fazla okuma:

1. REST API Tasarımı - Kaynak Modellemesi

Şu anda mikro hizmetlerin tüm öfke olduğunu biliyorum, ama her zaman buna değmez. Evet, gevşek birleştiğinde kod hedefidir. Ancak daha acı verici bir gelişme döngüsü pahasına olmamalıdır.

Çözümünüzde ayrı bir veri projesi oluşturmak iyi bir orta yol olacaktır. Veri projesi bir .NET sınıf kütüphanesi olacaktır. ASP.NET MVC projeniz daha sonra veri kitaplığına bir referans ekler ve tüm modeller veri projesinden çıkarılır. Sonra bir masaüstü veya mobil uygulama oluşturma zamanı geldiğinde, aynı koda başvurabilirsiniz. Bu yüzden resmi bir API olmayabilir, ancak tek olarak işlev görecek. Bir API olarak erişilebilir kılmak istiyorsanız, veri projesinde sarmalayıcı görevi gören basit bir web projesi oluşturabilirsiniz.

Microsoft, Taşınabilir Sınıf Kütüphaneleri olarak adlandırdıkları bu konsepti desteklemektedir .

Hayır yapmamalısın . Aynı arka uca erişen alternatif arayüzler (mobil veya masaüstü uygulamaları veya ayrı web uygulamaları gibi) oluşturma konusunda hemen planlarınız yoksa, bir web servis katmanı kullanmamalısınız. YAGNI .

Gevşek bağlantı her zaman arzu edilir (yüksek uyum ile birlikte), ancak bu bir tasarım prensibidir ve farklı sunuculardaki nesneleri fiziksel olarak ayırmanız gerektiği anlamına gelmez! Kötü tasarlanmış bir hizmet API'si sunucu sınırları boyunca sıkı bağlantı oluşturabilir, böylece bir API'ye sahip olmak gevşek bağlantıyı garanti etmez.

Bir hizmet API'sine olan ihtiyaç gelecekte ortaya çıkarsa, her zaman bu noktada onu tanıtabilirsiniz. Kodunuzu güzel bir şekilde katmanlı tuttuğunuz sürece (veri erişimi ve iş mantığı temiz bir şekilde UI mantığından ayrılmış), şimdi olduğundan daha sonra tanıtılması daha zor olmayacaktır. Ve ortaya çıkan tasarım gerçek gereksinimleri karşılamak üzere tasarlandığında daha iyi olacaktır.

Not Sorunun, bir web servisi API oluşturup oluşturmamanız gerektiğidir . Soru sadece API diyor, fakat API sadece bir kütüphanenin arayüzü anlamına da gelebilir ve elbette her katmanın tanımı gereği bir API olacaktır. Alt satırda, iş mantığınız ve veri erişim katmanlarınızın UI mantığından tasarım düzeyinde temiz bir şekilde ayrılması gerekir, ancak ihtiyacınız yoksa bir web hizmeti katmanı tanıtmamalısınız.

Şirketimin böyle inşa edilmiş bir uygulaması var. Başlangıçta, başka bir geliştiricinin oluşturduğu bir ön uç için API ile bir arka uç oluşturmak için görevlendirildik. Diğer geliştirici bu ön ucu geliştiremediğinde, ön ucu da yapmak üzere görevlendirildik. Bu yaklaşımın kesinlikle faydaları olmasına rağmen, büyük bir dezavantaj var: maliyet. İlk inşa önemli ölçüde daha pahalı olacak ve devam edecek bakım daha pahalı olacak, çünkü daha fazla kod bulundurmak ve iki ayrı sistemi de devreye almak. Ekstra maliyet nedeniyle, bu her zaman geliştiriciler tarafından kaprisli alınmayan bir iş kararı olmalıdır.

Buna değinmek gerekirse, yukarıda bahsettiğim projenin bu yaklaşım nedeniyle% 20 daha fazla maliyeti olduğunu tahmin ediyorum. Ne tür bir şirket için çalıştığınız üzerinde ne tür bir proje üzerinde çalıştığınızı tanımlamıyorsunuz, ancak bu ek maliyetlerin ürününü oluşturmaya başlarsanız, ürününüzü ekleyen birkaç ekstra özellik nakliye arasındaki fark olabilir başarı.

En azından evrensel olarak olmamak için bir başka neden, eğer bu ikinci arayüzü oluşturmaya karar verirseniz ya da ne zaman karar verirseniz, nadiren bire bir işlevsellik haritalaması olur. Örneğin bir mobil uygulama yaparsanız, daha az özelliğe sahip olma eğilimindedirler. Bu, bazı API yöntemlerinin tekrar kullanılmayacağı anlamına gelir. Bu nedenle, meslektaşınızla bir uzlaşma, sizin için en önemli / kritik çağrılar arasında karar vermek ve bir API'ye bunları eklemek ve her şey için daha geleneksel yöntemler kullanmak olabilir.

Dikkate alınması gereken bir diğer husus, iş arkadaşınızın, mevcut mantığınızı tekrar kullanamayacağınızı söylemektir, bu da işletme mantığınızdan biraz ayrılmanız durumunda doğru değildir. İç API'leriniz etrafında, özellikle de büyük bir görev olmayan ince bir web servis sarıcısı oluşturmanız yeterlidir. Herhangi bir değişiklik yapmadan bir web servis katmanını başka bir ön uç için yeniden kullanabileceğinizi düşünmek saf olurdu.

Bu, uygulamanın türüne ve içinde bulunduğunuz pazarın türüne bağlıdır.

Bu şekilde ilerlemenin sakıncaları ve faydaları var. Bir yolun diğerinden daha iyi olduğu kesin bir cevap değildir .

Kişisel deneyimlerden konuşacağım. 2007'de bu yönde üzerinde çalıştığım kod tabanını almaya karar veren bendim. Bu kod tabanı, şu anda milyonlarca kod satırında bir yerdedir, yarısı büyük miktarda web servisinin arkasına saklanmış sunucu kodudur. API'lerin diğer yarısı müşterilerin, masaüstü yerli, masaüstü web, mobil, arka uç entegrasyonların, vb. Bir filosudur ... Bu kararın dezavantajı yoktu, ancak 20/20 . İlgili takasların bazılarını belirteyim.

Yararları

• Esneklik. Masaüstü deneyimini artırmak için bir mobil uygulama oluşturma isteği veya SAP'nin arka planına entegre etme isteği olsun, zaten aramak için bir API'niz olduğunda, her şey daha kolay hale gelir. Bu isteklerden yeterince yararlandığınızda, organik olarak bir API'ye doğru evrimleşeceksiniz ve tek soru bunun önünde standart bir web servisinin olup olmadığı veya web servislerinin özel olarak hazırlandığı dahili bir API olup olmadığı.

• Ölçeklenebilirlik (ekibin). Bizim durumumuzda, bu API'nin üstüne inşa eden birçok farklı geliştirici grubumuz var. Farklı gruplarla konuşan, ihtiyaçları özetleyen ve bunun dışında çok amaçlı bir API oluşturan özel API ekiplerimiz bile var. Artık insanların bile API üzerinde bir şeyler inşa ettiklerini söylemediğimiz ve şirketimiz için çalışan herkesin olmadığı bir noktaya geldik.

• Güvenlik. Kod tabanınızın güvenli olmayan ve güvenli kısımları arasında net bir ayrım olması güvenliği düşünmenize yardımcı olur. Arayüzün birbirine karışması ve arka uç kodu birbirine karışmaya meyillidir.

Ticaret-off

• Esneklik. API’ya bir şeyleri “doğru bir şekilde” yerleştirmek için işi yapmanız gerekir. Belirli bir sorunu çözmek için UI kodunun içinden hızlı bir şekilde DB sorgusu çalıştırmak mümkün değildir. Ayrıca, gerçekte yeniden kullanılabilen API'ler, hızlı çözümün genellikle yanlış çözüm olduğunu göz önünde bulundurarak birçok kullanım durumunu dikkate almalıdır. API, özellikle dışarıda çok fazla müşteri kodu olduğu için gelişmesi daha az esnek hale geliyor (bu nedenle sürümlendirilmiş bir API'ye geçiyoruz).

• İlk gelişme hızı. Bir şüphe olmadan, ilk önce API geliştirmek daha yavaştır. Yalnızca API üzerine kurulu yeterli sayıda müşteriniz olduğunda kazanırsınız. Ancak, API'nizin yeterince genel olması için geliştirilmeden önce, 3 farklı müşteri uygulamasına ihtiyacınız olduğunu görürsünüz. İlk API tasarımlarımızın çoğunun yanlış olduğunu ve web hizmetlerinin nasıl oluşturulacağına ilişkin yönergelerimizi güçlü bir şekilde revize etmek zorunda kaldığımızı tespit ettik.

kırmızı ringa balıkları

Bunlardan bir demet bahsettin. Aslında pratikte önemli değil.

• Soyutlama. API’niz, ürününüzün hizmet etmesi gereken tüm kullanım durumlarını kapsayacak kadar soyut ve bundan daha fazlası olur. Web servisleri olmasa bile, bunu yapan dahili bir API'ye sahip olursunuz ya da birçok yinelenen kodunuz var. Çoğaltma yerine soyutlamayı tercih ederim.

• Sunucu tarafı MVC yığınını terk etmek. Bugünlerde hemen hemen her sistem bir süre sonra bir mobil uygulamaya ihtiyaç duyacak. Daha sonra bu mobil uygulamaya yanıt vermek için web hizmetleri oluşturduğunuzda, yine de bir API bağlamında nasıl kimlik doğrulama ve yetkilendirme yapılacağını çözmeniz gerekecektir. Bunu yapmanın sadece bir yolu olduğunda, web hizmetlerinizde yaptığınız gibi aslında daha az iş demektir.

• Toplu işlemler. Genellikle bir arka uç işi başlatan ve durum sorgulaması için bir iş kimliği döndüren toplu bir API oluşturarak çözülür. O kadar büyük bir anlaşma değil.

• Hata ayıklama. Sistemin sorunlarını gidermek için biraz daha kolaylaştığını gördüm. Sınır değerlerini hem ön hem de arka uç kodunda belirlemeye devam edebilirsiniz, bu nedenle pratikte adım atması zor değildir ve otomatik api testleri oluşturma ve üretim sistemlerini izlemek için api'yi kullanma yeteneği kazanırsınız.

• Birçok bağımsız işlem. Bu, şeyleri nasıl tasarladığınızla ilgili bir mesele. Saf bir CRUD API'sına sahip olmakta ısrar ederseniz, evet, bu sorundan muzdarip olacaksınız. Ancak, bazı CQRS API'lerinin tipik olarak iyi bir fikir olduğunu belirtmek için ve hizmetlerin ön uç olduğu dahili bir API’niz olduğundan emin olmuşsanız, bu dahili API’yi, bu servisler için servisler oluşturmak için kolayca yeniden kullanabilirsiniz. senaryo en.

Özetle

Yeterince farklı bağlamlarda kullanılan bir sistemde, bir API doğal olarak tüm ihtiyaçlara cevap vermenin en kolay yolu olduğu için gelişecektir. Ancak kesinlikle devam eden bir YAGNI vakası var. Takaslar var ve anlaşıncaya kadar mantıklı değil. Kilit nokta dogmatik olmamak ve ürünün gelişen ihtiyaçlarını karşılamak için mimaride farklı yaklaşımlara karşı açık bir zihni tutmaktır.

Meslektaşınızın tarif ettiği hizmet odaklı bir mimaridir. Bu, kodlamanın muazzam bir şekilde ölçeklenebilir, test edilebilir ve akıllıca bir yolu olabilir, ancak gerçekten ne yaptığınıza bağlıdır.

SOA’nın, numaralandırmaya çalışacağım bazı önemli yararları var:

Ölçeklenebilirlik

Arka ucunuz ayrıldığından, ön ucunuz sadece bir dizi şablon, hatta düz dosya haline gelir. Düz dosyalar, herhangi bir CDN'den servis yapmak için oldukça hızlı ve ucuzdur. Bunlar küçültülebilir ve statik HTML'ye önceden derlenebilir, ardından veri istemcileriyle doldurulabilir.

API'niz tutarlı kalmalıdır, ancak mevcut teknolojinizi atarsanız yığınınızı kırmadan daha hızlı bir teknoloji için değiştirilebilir. Örneğin Go'da yeniden yapabilirsiniz. Bu parçayı yeniden inşa edebilir ve yükü sunucular arasında dağıtabilirsiniz. Arayüz aynı kaldığı sürece teknoloji soyutlanır.

Testedilebilirlik

MVC genellikle temiz başlar, ancak pratikte kontrolörler nadiren tek bir kaynağa odaklanmış kalırlar. Denetleyici yöntemleriniz ne kadar çok şey yaparsa, test edilebilirler o kadar az test edilebilir.

Bir API bu konuyu takip etmez. Her bir API çağrısı bir kaynak çeker ve ona hizmet eder. Temiz ve test edilebilir.

Endişelerin ayrılmasının garanti altına alınması

Ön ucun ve arka ucun tamamen boşandı. Ön ucu başka bir geliştiriciye veya bir tasarımcıya verebilirsiniz. Bu MVC başka bir seviyeye alınır. MVC'den vazgeçmek istemeyeceğine eminim. SOA, MVC'dir, ancak daha fazlasıdır.

Downsides

Elbette bazı olumsuzluklar var. Bir monolit, başa çıkmak için genellikle daha hızlıdır. Alıştığınız şey olabilir. Yığına daha iyi sığabilir. Aletleriniz monolith oluşturma için optimize edilmiş olabilir.

Bunların hiçbiri benim görüşüme göre özellikle iyi nedenler değildir ve sizin için geçerliyse retooling düşünebilirsiniz.

Burada çok sayıda iyi cevap var, bu yüzden uygulama deneyimimi ekleyeceğim.

İşleri böyle yaparım:

• Yalnızca / yalnızca DB etkileşimini işleyen bir Veritabanı Erişim Katmanı oluşturun (genellikle manuel SQL, hız ve kontrol için kullanılır, ORM yoktur) . Ekle, Güncelle, Sil, Seç ...
• İhtiyacım olan API işlevlerini gösteren / uygulayan bir interface( virtual class) oluşturun . Uygulandığında, sonuçları elde etmek için oldukça uzmanlaşmış DBAL fonksiyonlarını kullanacaklar. Ayrıca, API'yi derleyici düzeyinde zorlamama da yardımcı oluyor, böylece Sunucu + API uygulamasının yerleşik tüm işlevlere sahip olduğundan emin oluyorum.
• Arayüzü uygulayan (asıl API budur) ve güvenlik kısıtlamalarını zorlayan İkinci Bir Katman oluşturun . Ayrıca burada harici API'ler ile de etkileşime girersiniz.
• Web sitesi, uzaktan erişilebilir bir API (SOAP, JSON gibi ) kullanmadan, İkinci Katmanı doğrudan (performans için) kullanacaktır .
• Arayüzü uygulayan ve İkinci Katmanı, harici masaüstü / mobil istemcilere (web sitesi dışı erişim) uzaktan erişilebilen gerçek bir API olarak gösteren bağımsız bir Sunucu . Tek yaptığı, istekleri özmek ve yanıtları kodlamak ve müşterileri yönetmek / bağlantıyı kesmek. Ayrıca, diğer bağlı meslektaşları tarafından oluşturulan olayların müşterilerini toplu olarak bilgilendirmek için pushback yeteneklerini de destekler (bir web sitesinin genellikle gerektirmediği işlevsellik) .

Yani, teknik olarak, API İkinci Katmandır. Doğrudan web sitesi ile kullanır ve bir sunucu aracılığıyla uzaktaki istemcilere sunarsınız. Kod yeniden kullanılıyor ve yeniden kullanılabilir bir kod parçası hiç satır içi değil. (bu kuralla yaşamak ve ölmek ve her şey mükemmeldir) Her şeyin korunmasına, test edilmesine yardımcı olur.

Web sitesini asla masaüstü / mobil API sunucusuna bağlamazsınız (siteniz AJAX değilse ve JSON'da çalışmıyorsa) . Ancak site işaretlemede dinamik içerik oluşturuyorsa, bir ara API üzerinden geçmek performansınızı etkileyecektir. Web sitesinin hızlı olması gerekiyor! Uzaktan istemci erişimi biraz daha yavaş olabilir.

Not : Evet, bakım daha fazla tekerlek birlikte çalıştığından biraz daha karmaşıktır, ancak uzun vadede daha kolaydır. Eğer projeniz bir süre yaşamak istiyorsa ve biraz karmaşıksa, her zaman bir API'ye sahip olursunuz. Ayrıca her katmanı kendi başına test etmek çok daha kolaydır.

Çekişme noktası bir API kullanmanız gerekip gerekmediği değil, gerçekte bir "API" olması gerektiğidir. Tasarlanmış bir API kullanmanın tek alternatifi, rastgele bir kod karışıklığı olan bir API kullanmaktır. Bir API'nin işleri "çok esnek" yaptığını ve bunun da yönetilemez hale getirdiğini yazıyorsunuz. Bu, bir API'nin ne olduğunu tam ve eksiksiz bir yanlış anlama işaret eder. Eğer bu yanlış anlama sizinle iş arkadaşınız arasında paylaşılmıyorsa, o zaman tamamen farklı şeyler tartışarak çok zaman kaybettiniz.

İyi tanımlanmış bir API kullanarak, ne istersen yapabilirsin. Tanım olarak bu en esnek seçenektir. Ayrıca, tanım gereği "ne istersen yap" hala bir API. Sadece bir API iş esnekliğini kaldırmaktır. Esnekliği ortadan kaldırarak iyi bir API, bir kullanıcıyı benzer şekillerde benzer şeyler yapmaya teşvik eder.

Tabii ki kötü bir API, aynı anda hem çok fazla hem de çok az esneklik sağlayabilir veya hatta her ikisini birden sağlayabilir. Gerçekten kötü tasarlanmış bir API, bir projeyi "her şey yolunda" yaklaşımından daha hızlı öldürebilir. Ancak, en iyi uygulama, uygulamanızla birlikte API'yi geliştiren ve geliştiren yetkin programcılara sahip olmaktır.

Örnek

• Çok sayıda geri ve ileri gerektiren bağımsız işlemlerin yapılması, örneğin bazı kodlar geçerli kullanıcıyı alabilir, kullanıcının yönetici rolünde olup olmadığını kontrol edebilir, kullanıcının ait olduğu şirketi, diğer üyelerin listesini alabilir, gönderebilir hepsi bir e-posta. Bu çok fazla API çağrısı gerektirebilir veya ısmarlama bir yöntemle istediğiniz belirli görevi yazabilir; ısmarlama yöntemin tek yararı hız olacaktır, ancak olumsuz tarafı ise esnek olamazdı.

Bunun için iyi bir API'de gerektirecek API çağrılarının sayısı muhtemelen 1 olacaktır. Evet, esnek değil, ama neden esnek olmasını istersiniz?

Kurallarımızın çok sıkı bir şekilde bağlı olduğunu söyledi. Örneğin, bir masaüstü uygulamasını da istersek, mevcut kodumuzu kullanamazdık.

Peki ya sen Eğer değilse, o zaman bu oldukça alakasız bir ifadedir.

2015 yılında yeni bir uygulama yapacaksanız , API içeren ve sunucu tarafından oluşturulan HTML sayfalarını içermeyen bir kullanıcı arayüzüne sahip olan bir şeye dikkatlice bakın. Net maliyetler ve net faydalar var.

Ancak , birkaç farklı arayüze (söyleyebileceğim kadarıyla) sahip olmak için somut bir planı olmayan mevcut bir siteniz varsa, yorumları sadece ilgisizdir.

Kısa Versiyon: Kontrolörünüz ne olursa olsun etkili bir API; ASP.NET bunu engelliyor olabilir.

Daha uzun versiyon:

Bira hakkında bilgi sağlayan ve isteğe bağlı olarak size bir tane satan temel bir MVC Web Uygulaması hakkında düşünün. Rotalar neye benziyor?

/sign_in
/sign_out
/beer
/beer/{beer_name}
/order
/order/{order_number}

Normal bir web uygulamasında, muhtemelen birkaç yardımcı yol vardır:

/beer/new
/beer/{beer_name}/edit
/beer/{beer_name}/delete
/order/new
/order/{order_number}/edit
/order/{order_number}/delete

Bir Web API'sinde, bunlar HTTP yönteminden çıkarıldığı için gerekli değildir.

Yukarıdaki simetri göz önüne alındığında, bunun API ve Kontrolörünüzün aynı şey olabileceği kadar yakın oldukları konusunda oldukça zorlayıcı bir durum olduğunu düşünüyorum.

Biraz kazı yaptıktan sonra, kullandığınız ASP.NET sürümüne bağlı olarak bunun sizin için durumların olabileceğini belirledim . Daha eski MVC 5 ve öncesi, iki uygulamayı sağlıklı bir şekilde birleştirmek için konvansiyonlar ve arayüz yoksundur. Eski sürümlerde, Web Uygulaması bir Görünüm döndürür, API ise bir HttpResponse verir. Her iki durumda da, aynı cevabı anlamsal olarak üretiyorlar .

MVC 6 kullanıyorsanız, her ikisini de ne geri döndüğü hakkında akıllıca olan birleştirilmiş bir denetleyici sınıfına girersiniz. Bu model için iyi bir ASP örnek kodu bulamadım, ancak aynı desende bazı Rails kodları buldum. Diaspora projesinden "beğenenler" için bu denetleyiciyi düşünün . Her denetleyici yönteminin, burada bir API'deki LCRUD'u belirten "becerikli bir kural" ile tanımlanan yolları vardır .

Ancak uygulamaları okursanız, her biri HTML, Mobil HTML veya JSON'a yanıt verebilir. Bu, görünümleri bulma konvansiyonuyla birleştirildiğinde, Web Uygulaması ve Web API'sini tamamen birleştirir. Ayrıca, tüm yöntemlerin aslında her yanıtı sağlamadığını da unutmayın (bu, kullanıcı arayüzünün API'nin uygulayamayacağı yöntemleri gerektirebileceği ve bunun tersi de olabilir).

Bu bir empedans uyuşmazlığıdır çünkü ASP.NET bir çeşit bu sorunu çözerken Rails bir süredir simetriyi benimsedi ve çok açık bir şekilde ortaya koydu.

Spekülasyon:

İş arkadaşınız muhtemelen hangi ASP sürümünü kullandığınıza bağlı olarak hem doğru hem de yanlış. Eski MVC versiyonuna göre, API ile App arasındaki fark muhtemelen API'yi önden inşa etmeyi "en iyi uygulama" haline getirdi çünkü ASP.NET'in modeli orada gerçekten iyi kod kullanımına izin vermiyordu.

Yeni olanla, birleşik kod kullanmak daha mantıklıdır çünkü birleştirilmiş denetleyici temel sınıfıyla kodu yeniden kullanmak daha kolaydı.

Her iki durumda da, Denetleyici etkin bir şekilde API'dir.

2006 yılında kariyerime başladığımda, bu tür bir mimarlık .NET dünyasındaki tüm öfkeydi. 2000'li yılların ortalarında tasarlanan 3 ayrı projede iş mantığı katmanı ve web ön yüzü arasında bir web hizmeti ile çalıştım. Tabii ki bugünlerde web servisleri SOAP'tı ancak yine de aynı mimari. Sözde faydalar ya ön ya da arka uç arasında geçiş yapabilme ve hatta masaüstü programını geliştirebilme yeteneği idi. Sonuçta YAGNI doğru olduğunu kanıtladı. Bunlardan hiçbirini hiç görmedim. Bunca zamandır projeyi bu şekilde bölmenin maliyetini gördüm. Hatta web servisini projelerden birinden kopardım (başka şeyleri yaparken adım adım kaldırması yarım yıl aldı) ve tüm ekip mutlu oldu. Bu yaklaşımı o zamandan beri hiç denemedim ve çok özel bir neden belirtilmediği sürece yapmayacağım. Bu mimariyi denediğim 5 yıllık tecrübe bana ihtiyacım olmayacağını öğretti ve bunun tersini söyleyen hiçbir uzman yok ki beni istediğime ikna edecek. Sadece ihtiyacım olan bir proje bunu yapabilir.

Şimdi söyleniyor ki, iş mantığı ile denetleyiciler / sunum yapanlar arasında bir katman geliştirmeye çalışıyorum. Örneğin, bir servis katmanım var, hiçbir zaman sorgulanabilirleri açığa çıkarmıyorum, tüm servislerim için arayüzleri kullanmıyorum ve onları IoC'li kontrol cihazlarına enjekte ediyorum. Mimarlığımda bir web servisine ihtiyacım olursa, bunu makul bir maliyetle tanıtabilirim. Sadece bu bedeli peşin olarak ödemek istemiyorum.

Ayrıca, mikro hizmetler fikrini de çok seviyorum ama benim anladığım kadarıyla mikro hizmetler yatay katmanlardan ziyade dikey modüller anlamına geliyor. Örneğin, facebook inşa ediyorsanız, sohbet özelliği kendi sunucularında ayrı olarak dağıtılan ayrı bir hizmet olacaktır. Bu, teşvik edeceğim bağımsız hizmetler türüdür.

Üçüncü taraflar kullanacak mı? Evet, yapmalısın .

Çok uzak olmayan bir gelecekte onu kullanmayı mı düşünüyorsun? Evet yapmalısın.
Üçüncü tarafınız olacak , belgelenmiş - ya da belgelendirilebilir - ya da üçüncü taraflarca kullanılabilir bir API olanağınız sağlam tekrar kullanılabilirlik ve modülerlik sağlayacaktır.

Acelen mi var? Hayır yapmamalısın.
Daha sonra yeniden yapılanmak, çoğu metodolojinin ve öğretmenin öngördüğünden ve söylediğinden daha kolay ve hızlıdır. İşe yarayan bir şeye sahip olmak (hatta kötü bir iç tasarıma sahip olsa bile, yeniden yapılabileceği gibi) hiçbir şey yapmamaktan daha önemlidir. (ama inanılmaz bir iç tasarıma sahip, wohoo)

Ön uç nedenlerden dolayı günün ışığını asla görmeyebilir? Evet, yapmalısın .
Bu sebebi ekledim çünkü bu bana çok şey oldu.
Ve en azından yeniden kullanma ve yeniden dağıtma vb.

Burada iyi cevaplar var. Bunu kısmi bir cevap olarak gönderiyorum; belki bir yorum olarak daha iyi olurdu. Ancak aynı yorumu sayısız yazıya yapıştırmak iyi değildir.

Bunlardan biri YAGNI'nin API oluşturmamak için bir sebep olduğunu iddia edemez.

API, doğal ve mantıklı bir test bitiş noktasıdır. Bu nedenle, 0 günden itibaren API'yi kullanan iki uygulama vardır: UI ve test paketi. Biri insanlar içindir, diğeri makineler içindir. Onlar mutlaka farklıdır. Ön uç davranışını test etmek, arka uç davranışını test etmekten çok farklı bir görevdir. Dolayısıyla teknikler ve muhtemelen araçlar tamamen farklıdır. API, iş için kullanılacak en iyi araca izin verir. Ayrıca, API tarafından sağlanan ayrımla, ön uç test uzmanlarının arka uç işlevselliğini test etmesi gerekmez.

API ayrıca, ön uç kodlayıcıların arka uç kodlayıcı endişelerinden uzak durmasına yardımcı olur ve bunun tersi de geçerlidir. Bunlar şirketimizde çok farklı becerilerdir; API, en güçlü olduğumuz yere odaklanmamızı sağlar.