Yeni Başlayanlar İçin Java Spring ile RESTful Service'in Yapısı

Java web geliştirme becerileri konusunda nispeten yeniyim. API'ler hakkında çok az şey anladığımdan RESTful hizmet için iyi bir aday olacağını düşündüğüm bir projem var. Bunun nasıl yapılandırılması gerektiğine dair ayrıntılara girmeye çalışıyorum, ama gerçekten google aramalar ve zaten sahip olduğum materyalleri okuma açısından herhangi bir yere ulaşmıyorum. Bu yazının, bu konudaki bilgim ve varsayımlarım açısından bazı doğrulama ve / veya yönlendirme getireceğini umuyorum.

Mevcut varsayımım, RESTful hizmetimin aşağıdaki yapıya sahip olacağı yönündedir:

• Veritabanı Verileri (SQL).
• Bir ORM (CPO adında nispeten popüler olmayan bir ORM kullanıyorum, ancak bu çoğu kişi ile Hazırda Bekletme ile değiştirilecek).
• Verileri elde etmek için ORM ile konuşan yöntemlere sahip bir Java yöneticisi sınıfı
• Bir Java denetleyici sınıfı / kolları haritalama ve kullanımları istemeleri sınıfları @ResponseBodydoğrudan / HTTP fiiller aracılığıyla URL'yi ve veri nasıl işlendiğini eylemlerini işlemek ( http://mysite.com/computers/dell olabilir GETkelime "dell" ile istek URL'de, dell bilgisayarlar hakkında bir JSON bilgi dizisi döndürecek bir parametredir).
• Bu hizmet Spring Boot ile yapılmalıdır veya bir şekilde tek başına durabilir ve diğer uygulamalardan bağımsız olabilir.

Şimdi yukarıdakilerin doğru olduğunu varsayarsak, o zaman (çok temel düzeyde) herhangi bir uygulamanın veri tüketmek ve kullanmak için kullanabileceği bir RESTful hizmetim olurdu.

Diyelim ki web uygulamam var. Bilgisayar donanım bilgileri hakkında bir web uygulaması yaptığımı ve bu web uygulamasını oluşturmak için Spring'i kullandığımı varsayalım. İşte benim varsayımlarım:

• JSP'ler, HTML, CSS ve JavaScript içeren JSP'lerle bir sürü görünümüm olurdu. JavaScript gerektiğinde bu uygulamanın denetleyicisine AJAX çağrılarını işleyecektir (aşağıda).
• Bu web uygulaması ayrıca uygulamanın URL isteklerini ve yönlendirmesini işlemek için kendi denetleyicisine sahip olacak ve denetleyici daha sonra ModelAndViewRESTful hizmetinin denetleyicisiyle "konuşmak", iletilen veriyi elde etmek için bu satırlardaki nesneyi veya bir şeyi kullanır. , görüntülemek için bu verileri görünüme (Javascript, JSP vb.) geri aktarın.

Burada doğru yolda mıyım? RESTful hizmetlerinde bir kimlik doğrulama özelliği olduğunu da anlıyorum, ancak henüz kavramsal olarak orada değilim (ve projem özel bir ağda kullanılacak, bu nedenle güvenlik bu noktada bir öncelik değil).

Herhangi bir içgörü, eleştiri, bilgi, geri bildirim veya açıklama büyük beğeni topluyor.

İşte bahar dinlenme uygulamanız için yapının en sevdiğim başlangıç ​​örneklerinden biri.

1. katmanların Ayrılması, her katman bireysel bir modül / proje

• REST API'sı
  • Savaş olarak paketlenmiştir ( Gömülü sunucu ile yaylı önyükleme kullanıyorsanız kavanoz olabilir . Bahar önyükleme dokümanı, uber kavanozu nasıl dağıtacağınızı açıkça açıklar . Ölümcül basittir.)
  • İstek / yanıtları işleyen dinlenme denetleyicileri vardır
  • aşağıdaki Servis Modülüne bağlıdır
• Hizmet
  • Kavanoz olarak paketlenmiş
  • İş mantığı soyutlamaları, bu katmanın veri kaynağı ile nasıl iletişim kuracağı hakkında hiçbir fikri yoktur.
  • Bu edilecek autowired dinlenme kontrolörleri içinde
  • Bağlı DAO / Depo altına modül
• DAO / Depo
  • Kavanoz olarak paketlenmiş
  • Doğrudan veri kaynağı ile yapılan görüşmelerde, genel olarak CRUD olarak bilinen işlemler vardır. Basit jdbc, JPA ve hatta dosya erişimi olabilir.
  • Aşağıdaki alan adı modülüne bağlıdır
• Alan adı
  • Kavanoz olarak paketlenmiş
  • Etki alanı modelleriniz, normalde POJO sınıfları var. ORM kullanıyorsanız, bunlar ORM varlıklardır.
  • Ayrıca hala sıcak tartışmalar altında olan DTO (Veri Aktarım Nesnesi) olabilir. Kullan ya da kullanma çağrınız.
• Yardımcı program, üçüncü taraf entegrasyonu vb. Gibi daha fazla modül ekleyebilirsiniz.

2. Derleme / Bağımlılık Yönetim Araçları (Çok gerekli IMHO)

Onlardan bir sürü var, google arama size gösterecektir. Şahsen Spring ile Maven'i seviyorum . Sadece yukarıdaki proje yapısı için çalışır.
Ayrıca maven kullanıyorsanız, bölüm 1'de tartışılan tüm modülleri toplayan bir ana modül bulunduğunu unutmayın. Tüm madde işareti modülleri de maven modüllerine karşılık gelir.

3. Projenizle ilgili düşünceler

REST kullandığınızdan, JSP'yi görünümünüz olarak KULLANMAYINIZ. Düz HTML5 + Javascript'i veya AngularJS gibi popüler bir çerçeveyi görünümünüz olarak kullanabilirsiniz.
JSP kullanmakta ısrar ederseniz , denetleyicileri ve JSP'leri olan başka bir savaş (web uygulaması) tanıtmanız gerekir . Denetleyici verileri alır (Normalde Json / xml biçimi) ve sonra JSP'nizin denetleyicinizden alabilmesi ve ekranı yapabilmesi için bunları modellerinize (POJO) ayrıştırın. JSP veri göndermek tersidir, burada atlanmış.

Bu konu oldukça büyük olduğundan ve büyük ölçüde sizin özel gereksiniminize bağlı olduğu için tam bir kılavuzun yakınında değildir, ancak burada yer alan terimler ek araştırma yapmanız için yeterlidir (Google, öyle). Umarım bu size nasıl yaklaşacağınız konusunda bazı fikirler verecektir.

@ Minjun.Y'nin cevabının çoğunu kabul ederken, REST ve Web sayfası katmanına biraz farklı bir yaklaşım getireceğimi düşünüyorum. Sorunuzu okuduğumdan, hem bir web arayüzünü hem de bir REST arayüzünü dış dünyaya tanıtmak istediğinizi düşünüyorum. Veritabanından POJO'ları okuyarak, verileri JSON'a çevirerek ve sonra JSP'ler tarafından tüketilmek üzere POJO'lara dönüştürülerek elde edilecek çok az şey vardır.

Ben hizmet katmanı tüm gerçek işi yapmak ve web uygulaması (JSPs) ve REST denetleyicisi için ayrı "sunum" katmanları eklemek istiyorum. Bunlar, servisin enjekte edileceği ayrı kontrolörler olacaktır. Alternatif olarak, sadece bir REST hizmeti ile gidin ve önceki yanıta göre tüm sunum mantığını istemci tarafında oluşturun.

Ayrıca Maven modüllerinin büyük bir hayranı değilim. Java mağazamızın projenizi uygulama şekli, hizmet katmanını düzenli olarak yayınlamak ve ardından sunum katmanlarını en son sürüme bağımlı hale getirmek olacaktır. Bu konuda tartışmaya yer var, ama kesinlikle bizim için çalışıyor. Web arayüzü ve REST arayüzleri ayrı Maven projeleri olarak olurdu, çünkü normalde farklı .war dosyalarında yaşıyorlar ve bu nedenle ayrı dağıtım gerektiriyorlar.

BTW, yapı ve bağımlılık yönetimi araçlarıyla hızlanma ihtiyacını pekiştiririm. Projeniz makul bir boyuta ulaştığında, onlara ihtiyacınız var. Maven, Jenkins ve Nexus gibi ücretsiz araçlar, sürüm yönetimini daha az sorun haline getirir.