Kasıtlı olarak REST standartlarını ihlal eden bir mimari değişim nasıl tarif edilir?

Çok sayıda sorundan muzdarip, çok zayıf mimariye sahip bir yazılım projesinde değişiklikler öneriyorum. Yüksek düzeyde proje ön uçta Angular kullanır ve çeşitli REST API'leri kullanır; hangisi harika (teknolojimizi veya araçlarımızı değiştirme gereği duymuyorum). Sorun, kod tabanının UI'da sunucu tarafı API'lerden daha büyük olması. İş mantığının çoğu UI'de yaşar, REST API'leri basit CRUD veritabanıdır ve UI katmanına arayüz oluşturur.

Örneğin, müşteriye bir POST bir müşteri kaydı yaratacaktır, PUT ise bu müşteriyi değiştirecektir. Çok fazla değil ve çok az değil. Ancak iş mantığımız bundan daha talepkar. Bir müşteri yaratmanın genel süreci, 1 veritabanı kaydı eklemekten çok daha fazlasını yapar. Diğer gerekli tablolarda veri sağlayacak, belirli doğrulama ve hesaplamaları yapacaktır. Tüketici müşterinin yükünü hafifleterek tüm bu davranışı içine alan tek bir POST / PUT çağrısı yapmayı tercih ederim.

Dolayısıyla benim bakış açım, bu genel düzenlemenin UI'de değil, sunucuda (tam denetime sahip olduğumuz, günlükler vb.) Yaşaması gerektiğidir, ancak bir karşı iddia bu yaklaşımın artık RESTful olamayacağıdır. Bu yüzden, tavsiyem mevcut teknoloji yığına devam etmek, ancak kodun ait olduğu yerlerde temel kaymalar uygulamak olduğunda bu yaklaşımı en iyi nasıl tanımlayacağımı bilmiyorum.

Tavsiyem mevcut teknoloji yığınıyla devam etmek, ancak kodun ait olduğu yerlerde temel kaymalar uygulamak olduğunda bu yaklaşımı en iyi nasıl tanımlayacağımı bilmiyorum.

Service oriented architecture.

İş kurallarınız ve verileriniz aynı yerde olacak şekilde sisteminizi yeniden tasarlamayı öneriyorsunuz. Bu etkili bir hizmetin tanımıdır ; Udi Dahan'ın Hizmet Sınırlarını Bulma konusundaki konuşmasını görün .

Kenar çubuğu: Eric tarafından belirtildiği gibi, bunun "REST" ile ilgisi yoktur. Hizmetinizin önüne bir REST API'si (yani, REST mimari stilinin sınırlarını sağlayan bir API) koyamazsınız kesinlikle hiçbir sebep yoktur . Ancak bu, REST'i anlayan insanlar için veritabanı işlemlerinin HTTP yöntemleriyle eşlenmesi anlamına gelmeyebilir.

Hedef kitlenizin REST anlayışını değiştirmeye yatırım yapmaya değer olabilir veya olmayabilir.

REST CRUD değil. Bu "karşı karşılama", REST'in ne olduğuna dair temelde kusurlu bir anlayışa dayanıyor. Gönderinizde, yaptığınız değişikliğin API'nizi daha az veya daha fazla RESTful yapacağını gösteren hiçbir şey görmedim.

Akılda tutulması gereken bir şey daha var ... İş kuralları sunucu tarafında doğrulamak değil, bir POST isteği söyleyerek gelen herhangi bir şeyi örtülü olarak güvendiğiniz anlamına gelir.

Örneğin, açısal başvurunuz müşterinin geçerli bir yaş aralığında olup olmadığını kontrol edebilir ve meşru kullanıcıların doğru geribildirim almasını sağlarken, API'nizin URL’sini bilen herkes yasal olmayan bazı değerler içeren bir POST isteği yapabilir. artık doğrulanmadı.

Bu yüzden önerim, işletme kurallarınızı API'ye taşımak, girişi doğrulamasına ve yanıtın gövdesinde uygun hataları (ya da belki de neyin yanlış gittiğini gösteren kodları) vermesine izin vermek olacaktır. Bu kodlar, ön uç uygulamanız tarafından neyin yanlış gittiğini belirtmek için kullanılabilir.

Diğer iyi cevapları buraya eklemek için:

Arayüzünüz, REST ya da başka bir şekilde, uygulama detaylarıyla ilgili bazı varsayımlara dayanarak kısıtlanmamalıdır. Bu, soyutlama katmanı olarak hizmet kavramına tamamen aykırıdır.

Servisleri kullanmanın temel faydalarından biri, uygulama detaylarının müşterilerin bir şey yapması gerekmeden değiştirilebilir. Tarif ettiğinize göre, gerçek bir soyutlama katmanı yokmuş gibi geliyor. Uygulamanın detayları HTTP yoluyla ortaya kondu. REST ile ilgili hiçbir şey bunun gerekli, faydalı veya arzu edilen olduğunu söylemez. Aslında, bunun REST dışı bir uygulama olduğu anlamına geldiği için REST tanımının bazı kısımlarını tartışabileceğimi düşünüyorum .

Önerdiğiniz şey, uygun bir servis katmanının nasıl tasarlanması gerektiğidir. Birisi size yapamayacağınızı söylüyorsa, çünkü RESTful değildir, bu talihsiz bir durumdur. Size söyleyen birinin REST hakkında hiçbir şey bilmediğinden emin olabilirsiniz.

Sorunuza dayanarak, müşteri adında bir kaynağınız var. Geçerli bir müşteri kaynağı oluşturmak için gereken her şey ve her şey POST, müşteri temel kaynağında (ya da isteğe bağlı olarak / isteğe bağlı olarak PUT'ta belirli bir müşteri kaynağına mevcutsa, işlenebilmeli) kullanılmalıdır ve yapılmalıdır . Belirli bir aramada oluşturmanız gereken veritabanı kayıtları. Colin Young’un dediği gibi, hiçbir veri tabanı olması gerekmiyor, hizmetlerin REST bakış açısından nasıl uygulanacağı tamamen alakasız.

Burada bazı iyi cevaplar var, ancak iş arkadaşlarınızı ikna etmenize yardımcı olacaklarından emin değilim. Pek çok kişinin belirttiği gibi, önerdiğiniz şey RESTful tasarımdan uzaklaşmak değildir, ve bunun teklifinizle ilgili bir öneride bulunmanın anahtarı olduğunu düşünüyorum.

REST, API'nizin yalnızca veri depolamaya ve almaya izin verdiğinden emin olmakla ilgili değildir . Daha ziyade, kaynak olarak modelleme eylemleriyle ilgilidir . API gerekir (bir uygulama olduğunu Alınacak hareketleri sağlayan Programlama sonuçta Arabirimi). Soru, bu eylemlerin nasıl modelleneceğidir.

Bir terim bulmak yerine, örnekler muhtemelen bunu iş arkadaşlarınıza açıklamanın en iyi yoludur . Bu şekilde şimdi nasıl yaptıklarını, bunun hangi sorunlara neden olduğunu, sorunu çözen bir çözümü ve hala nasıl RESTful olarak kaldığını gösterebilirsiniz.

Müşteri hedefinize bakalım.

Sorun:

UI bir Müşteriyi POSTS, ancak sonraki tablolar henüz güncellenmedi. UI kodunuzdaki (veya tarayıcı eklentisini kötüleyen vb.) Bir hata nedeniyle sonraki çağrılardan biri başarısız olursa ne olur? Şimdi verileriniz tutarsız bir durumda. API veya kullanıcı arayüzünüzün diğer bölümlerini kıran bir durum bile olabilir, bunun sadece geçersiz olduğunu söylememek değil. Nasıl iyileşirsiniz? Bunun bir şeyi bozmayacağından emin olmak için her olası durumu test etmek zorunda kalacaksınız, ancak neyin mümkün olduğunu bilmek zor olacaktır.

Çözüm:

Müşterileri oluşturmak için bir API uç noktası yapın. Bir "/ customer / create" veya hatta "/ create-customer" bitiş noktasına sahip olmak istemediğinizi biliyorsunuz, çünkü create bir fiildir ve REST'i ihlal eder. Yani bunu duyurun. "/ müşteri yaratma" işe yarayabilir. Artık CustomerCreation nesnesini POST yaptığınızda, bir müşterinin tamamen oluşturulması için gerekli tüm alanları gönderir. Bitiş noktası, verilerin eksiksiz ve geçerli olmasını (doğrulama başarısız olursa 400 ya da başka bir şey döndürerek) olmasını sağlar ve örneğin, tek bir db işleminde devam edebilir.

Ayrıca, GET / müşteri nesneleri için bir son noktaya ihtiyacınız varsa, sorun değil. İkisine de sahip olabilirsin. İşin püf noktası, tüketicilerin ihtiyaçlarına hizmet edecek uç noktalar yaratmaktır.

Avantajları:

1. Kötü halin olmayacağını garanti edersin
2. Talep sıralamasını, onaylama endişelerini vb. "Bilmek" zorunda kalmazlarsa UI devs için aslında daha kolaydır.
3. Ağ isteklerinin gecikmesini azaltan bir API'nin konuşkanlığı değildir.
4. Senaryoları test etmek ve kavramsallaştırmak daha kolaydır (kullanıcı arayüzünde eksik / hatalı biçimlendirilmiş veri parçaları isteklere yayılmaz, bazıları başarısız olabilir)
5. İş mantığının daha iyi kapsüllenmesine izin verir
6. Genel olarak güvenliği kolaylaştırır (çünkü kullanıcı arayüzündeki işletme ve düzenleme mantığı kullanıcılar tarafından değiştirilebilir)
7. Mantıksal çoğaltmayı büyük olasılıkla azaltacaktır (aynı verilere erişim sağlayan 2+ API'dan daha fazla 2+ API tüketicisi olacak)
8. Hala% 100 RESTful

Dezavantajları:

1. Arka uç dev için potansiyel olarak daha fazla çalışma (ancak uzun vadede olmayabilir)

İnsanların bu paradigmayı ve eğer denememişlerse iyi olanı anlamaları zor olabilir. Umarım, kendi kodunuzdan bir örnek kullanarak onların görmesine yardımcı olabilirsiniz.

Benim kendi deneyimim, ekibimdeki geliştiriciler bu stratejiyi uygulamaya başladıklarında, faydaları hemen hemen gördükleridir.

İlerideki çalışma:

Düşüncelerden yazılan bu makale, pratik örnekler kullanarak eylemleri nesneler olarak modelleme fikrini edinmeme yardımcı oldu: https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling

Ayrıca, tam da bu tür şeylerle ilgilendikleri için CQRS ve Etkinlik Kaynaklarını okumayı da öneririm (örneğin , API'nizi gerçek sebat mantığından ayırma ). İş arkadaşlarınızın bu tür şeyleri okumak için ne kadar istekli olduklarını bilmiyorum, ancak size daha fazla netlik verebilir ve onlara açıklamanıza yardımcı olabilir.