Struktura usługi RESTful z Java Spring dla początkujących


12

Jestem stosunkowo nowy, jeśli chodzi o umiejętności programowania stron internetowych w Javie. Mam projekt, który moim zdaniem byłby dobrym kandydatem do usługi RESTful z tego, co niewiele rozumiem na temat interfejsów API. Próbuję zagłębić się w szczegóły tego, jak to powinno być zorganizowane, ale tak naprawdę nie docieram nigdzie pod względem wyszukiwań w Google i czytania materiałów, które już mam. Mam nadzieję, że ten post przyniesie pewne potwierdzenie i / lub przekierowanie pod względem mojej wiedzy i założeń na ten temat.

Moje obecne założenie jest takie, że moja usługa RESTful będzie miała następującą strukturę:

  • Dane bazy danych (SQL).
  • ORM (używam stosunkowo niepopularnego ORM o nazwie CPO, ale w przypadku większości ludzi to po prostu zastąpiłoby Hibernacja).
  • Klasa menedżera Java z metodami komunikującymi się z ORM w celu uzyskania danych
  • Klasa / klasy kontrolera Java, które obsługują mapowanie żądań i używają @ResponseBodydo kierowania / obsługi adresu URL i działań związanych z przetwarzaniem danych za pomocą czasowników HTTP ( http://mysite.com/computers/dell może być GETżądane ze słowem „dell” w adresie URL będącym parametrem, który zwróci tablicę JSON informacji o komputerach Dell).
  • Ta usługa powinna być wykonywana za pomocą Spring Boot lub w jakiś sposób być w stanie działać samodzielnie i być niezależna od jakiejkolwiek innej aplikacji.

Teraz, zakładając, że powyższe jest poprawne, miałbym (na bardzo podstawowym poziomie) usługę RESTful, której każda aplikacja może użyć do konsumpcji i wykorzystania danych.

Powiedzmy, że mam swoją aplikację internetową. Załóżmy, że tworzę aplikację internetową na temat informacji o sprzęcie komputerowym i używam Springa do jej zbudowania. Oto moje założenia:

  • Miałem wiele widoków jako strony JSP, przy czym strony JSP zawierały HTML, CSS i JavaScript. JavaScript obsłuży wywołania AJAX do kontrolera tej aplikacji w razie potrzeby (poniżej).
  • Ta aplikacja internetowa miałaby również własny kontroler do obsługi żądań i routingu adresów URL aplikacji, a następnie kontroler użyłby, powiedzmy, ModelAndViewobiektu lub czegoś w tym stylu do „rozmowy” z kontrolerem usługi RESTful, uzyskując wszelkie przekazywane dane , przekaż te dane z powrotem do widoku (JavaScript, JSP itp.) w celu wyświetlenia.

Czy jestem na dobrej drodze, tutaj? Rozumiem, że istnieje również aspekt uwierzytelniania usług RESTful, ale nie jestem jeszcze tam koncepcyjnie (i mój projekt będzie wykorzystywany w sieci prywatnej, więc bezpieczeństwo nie jest w tym momencie priorytetem).

Każdy wgląd, krytyka, wiedza, opinie lub wyjaśnienia są bardzo mile widziane.

Odpowiedzi:


19

Oto jeden z moich ulubionych przykładów struktury Twojej aplikacji do odpoczynku wiosennego.

1. Rozdzielanie warstw, każda warstwa to osobny moduł / projekt

  • Interfejs API REST
    • Pakowane jako wojna (może być słoikiem, jeśli używasz rozruchu wiosennego z wbudowanym serwerem. Dokument rozruchowy jasno wyjaśnia, jak wdrożyć tak zwany słoik Uber . Jest to śmiertelnie prosta).
    • Ma kontrolery odpoczynku, które obsługują żądania / odpowiedzi
    • zależy od modułu serwisowego poniżej
  • Usługa
    • Pakowane jako słoik
    • Abstrakcje logiki biznesowej, ta warstwa nie ma pojęcia, jak komunikować się ze źródłem danych.
    • Zostanie on automatycznie włączony w kontrolerach spoczynkowych
    • Zależy od poniższego modułu DAO / repozytorium
  • DAO / Repository
    • Pakowane jako słoik
    • Rozmawia bezpośrednio ze źródłem danych, ma operacje powszechnie znane jako CRUD. Może to być prosty dostęp do plików jdbc, JPA, a nawet.
    • Zależy od modułu domeny poniżej
  • Domena
    • Pakowane jako słoik
    • Ma twoje modele domen, zwykle klasy POJO. Jeśli używasz ORM, są to podmioty ORM.
    • Może również mieć DTO (Data Transfer Object), które są nadal przedmiotem gorących debat. Użyj tego, czy nie.
  • Możesz dodać więcej modułów, takich jak narzędzie, integracja z firmą zewnętrzną itp., Ale zaleca się, aby powyższe były.

2. Narzędzia do zarządzania kompilacją / zależnościami (bardzo potrzebne IMHO)

Jest ich wiele, wyszukiwarka Google pokaże. Osobiście lubię Maven with Spring. Po prostu działa dla powyższej struktury projektu.
Zauważ też, że jeśli używasz maven, istnieje moduł nadrzędny, który agreguje wszystkie moduły omówione w rozdziale 1. Wszystkie moduły punktorów również odpowiadają modułom maven.

3. Myśli na temat konkretnego projektu

Ponieważ używasz REST, zdecydowanie NIE zalecam używania JSP jako widoku. Jako widoku możesz użyć zwykłego HTML5 + JavaScript lub popularnego frameworka, takiego jak AngularJS.
Jeśli nalegasz na używanie JSP, musisz wprowadzić kolejną wojnę (aplikację internetową), która ma kontrolery i JSP. Kontroler pobierze dane (normalnie format Json / xml), a następnie parsuje je do modeli (POJO), aby JSP mógł je pobrać z kontrolera i wyświetlić. Przesyłanie danych z JSP jest odwrotne, pominąłem tutaj.

Nie jest to kompletny przewodnik, ponieważ ten temat jest dość obszerny i zależy w dużej mierze od konkretnych wymagań, ale zawarte w nim warunki wystarczą, aby przeprowadzić dodatkowe badania (Google, to jest). Mam nadzieję, że da ci to kilka pomysłów na podejście.


1
Domena to zazwyczaj warstwa zawierająca logikę biznesową. Domena jest zwykle określana również jako warstwa zawierająca usługi. Obiekty domeny nie są zwykłymi POJO. Obiekt domeny powinien zawierać logikę biznesową, taką jak sprawdzanie poprawności argumentów i jako taki. Prawdopodobnie lepiej byłoby zmienić nazwę warstwy na coś innego. Warstwa repozytorium jest również dość często używana do przesyłania danych z wielu źródeł do obiektów domeny.
Andy

Czy moduły usługi i repozytorium będą również projektami wiosennymi?
Glenn Van Schil

1
@GlennVanSchil Nie, nie muszą to być wiosenne projekty b / c, gdy cały projekt jest budowany, warstwa repo / service zostanie uwzględniona w ścieżce klas. W @Autowirerezultacie zadziała.
Minjun Yu,

@MinjunYu Dzięki za jasną odpowiedź! Ale twoje repozytorium / usługa potrzebuje sprężyny, ponieważ adnotacje dotyczące usługi, repozytorium lub komponentu są zależne od maven, czy mam rację?
Glenn Van Schil

1
@GlennVanSchil Jeśli umieścisz wszystkie zależności Spring Maven w pom.xml modułu nadrzędnego, nie będzie potrzeby dodawania żadnych zależności związanych ze sprężyną w modułach potomnych (moduły repo / service). To tylko jeden sposób na wiosnowanie projektów z wieloma modułami. Celem jest uporządkowanie kodu. Jeśli Twój projekt nie jest tak duży i nie zmieni się w dającej się przewidzieć przyszłości, możesz połączyć domenę, repozytorium i usługę w tym samym module o nazwie „core”. Wygląda jeszcze czystiej.
Minjun Yu,

2

Zgadzając się z większością odpowiedzi z @ Minjun.Y, myślę, że wybrałbym nieco inne podejście do REST i warstwy strony internetowej. Po przeczytaniu twojego pytania, myślę, że chcesz odsłonić zarówno interfejs WWW, jak i interfejs REST na zewnątrz. Niewiele można zyskać czytając POJO z bazy danych, przekształcając dane w JSON, a następnie z powrotem w POJO do wykorzystania przez JSP.

Wolałbym, aby warstwa usługi wykonała całą prawdziwą pracę i dodała osobne warstwy „prezentacji” dla aplikacji sieci Web (JSP) i kontrolera REST. Byłyby to osobne kontrolery, do których wprowadzana byłaby usługa. Możesz też skorzystać z usługi REST i zbudować całą logikę prezentacji po stronie klienta, zgodnie z poprzednią odpowiedzią.

Nie jestem też wielkim fanem modułów Maven. Sposób, w jaki nasz sklep Java wdrożyłby twój projekt, polegałby na regularnych wydaniach warstwy usługowej, a następnie uzależnieniu warstw prezentacji od najnowszej wersji. Jest tu miejsce na dyskusję na ten temat, ale z pewnością działa dla nas. Interfejs internetowy i interfejsy REST mielibyśmy jako osobne projekty Maven, ponieważ zwykle znajdują się one w różnych plikach .war i dlatego wymagają osobnego wdrożenia.

BTW, wzmocnię potrzebę przyspieszenia dzięki narzędziom do kompilacji i zarządzania zależnościami. Gdy Twój projekt osiągnie odpowiedni rozmiar, potrzebujesz go. Bezpłatne narzędzia, takie jak Maven, Jenkins i Nexus, sprawiają, że zarządzanie wydaniami nie stanowi większego problemu.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.