Struttura del servizio RESTful con Java Spring per principianti


12

Sono relativamente nuovo in termini di capacità di sviluppo web Java. Ho un progetto che penso sarebbe un buon candidato per un servizio RESTful da quel poco che capisco sulle API. Sto cercando di entrare nei dettagli di come dovrebbe essere strutturato, ma di non arrivare davvero da nessuna parte in termini di ricerche su Google e leggere il materiale che già ho. Spero che questo post produca un po 'di validazione e / o reindirizzamento in termini di mie conoscenze e ipotesi su questo argomento.

La mia ipotesi attuale è che il mio servizio RESTful avrà la seguente struttura:

  • Database Database (SQL).
  • Un ORM (sto usando un ORM relativamente impopolare chiamato CPO, ma questo sarebbe semplicemente sostituito con Hibernate con la maggior parte delle persone).
  • Una classe manager Java con metodi che parlano all'ORM per ottenere i dati
  • Una classe / classi di controller Java che gestisce il mapping delle richieste e utilizza @ResponseBodyper dirigere / gestire l'URL e le azioni su come i dati vengono gestiti tramite verbi HTTP ( http://mysite.com/computers/dell potrebbe essere GETrichiesto con la parola "dell" essendo l'URL un parametro che restituirà una matrice JSON di informazioni sui computer dell).
  • Questo servizio dovrebbe essere realizzato con Spring Boot, o in qualche modo essere in grado di stare da solo ed essere indipendente da qualsiasi altra applicazione.

Ora supponendo che quanto sopra sia corretto, allora avrei (a un livello molto semplice) un servizio RESTful che qualsiasi applicazione può utilizzare per consumare e utilizzare i dati.

Quindi dì che ho la mia applicazione web. Diciamo che sto realizzando un'app Web sulle informazioni sull'hardware del computer e sto usando Spring per creare questa app web. Ecco i miei presupposti:

  • Avrei un sacco di punti di vista come JSP, con i JSP con HTML, CSS e JavaScript inclusi. JavaScript gestirà le chiamate AJAX al controller di questa applicazione, se necessario (di seguito).
  • Questa app Web avrebbe anche un proprio controller per gestire le richieste e il routing dell'URL dell'app e quindi il controller userebbe, diciamo, l' ModelAndViewoggetto o qualcosa del genere per "parlare con" il controller del servizio RESTful, ottenere qualunque dato venga passato , restituisci quei dati alla vista (Javascript, JSP, ecc ...) per la visualizzazione.

Sono sulla buona strada, qui? Capisco che c'è anche un aspetto di autenticazione nei servizi RESTful, ma non ci sono ancora concettualmente (e il mio progetto verrà utilizzato in una rete privata, quindi la sicurezza non è una priorità a questo punto).

Qualsiasi approfondimento, critica, conoscenza, feedback o chiarimento è molto apprezzato.

Risposte:


19

Ecco uno dei miei esempi kick-off preferiti di struttura per la tua app di riposo a molla.

1. Separazione dei livelli, ogni livello è un singolo modulo / progetto

  • API REST
    • Impacchettato come guerra (potrebbe essere jar se si utilizza l' avvio di primavera con il server incorporato. Il documento di avvio di primavera spiega chiaramente come distribuire il cosiddetto Uber Jar . È mortalmente semplice.)
    • Ha controller di riposo che gestiscono richieste / risposte
    • dipende dal modulo di servizio di seguito
  • Servizio
    • Confezionato come barattolo
    • Astrazioni di business logic, questo livello non ha idea di come comunicare con l'origine dati.
    • Sarà autowired nei controller di riposo
    • Dipende dal modulo DAO / Repository di seguito
  • DAO / Repository
    • Confezionato come barattolo
    • Parla direttamente all'origine dati, ha operazioni comunemente note come CRUD. Potrebbe essere semplice jdbc, JPA o persino l'accesso ai file.
    • Dipende dal modulo di dominio di seguito
  • Dominio
    • Confezionato come barattolo
    • Ha i tuoi modelli di dominio, normalmente classi POJO. Se si utilizza ORM, sono entità ORM.
    • Potrebbe anche avere DTO (Data Transfer Object), che è ancora oggetto di dibattiti. Usalo o no è la tua chiamata.
  • È possibile aggiungere più moduli come utilità, integrazione di terze parti, ecc. Ma si consiglia vivamente di avere quanto sopra.

2. Strumenti di gestione build / dipendenze (IMHO molto necessario)

Ce ne sono molti, la ricerca di Google ti mostrerà. Personalmente mi piace Maven con Spring. Funziona semplicemente per la struttura del progetto sopra.
Si noti inoltre che se si utilizza maven, esiste un modulo padre che aggrega tutti i moduli discussi nella sezione 1. Tutti i moduli punto elenco corrispondono anche ai moduli maven.

3. Pensieri sul tuo progetto particolare

Dal momento che stai usando REST, ti consiglio vivamente di NON usare JSP come tuo punto di vista. Puoi usare HTML5 + Javascript o alcuni framework popolari come AngularJS come visualizzazione.
Se insisti nell'uso di JSP, dovrai introdurre un'altra guerra (app Web) con controller e JSP. Il controller otterrà i dati (normalmente formato Json / xml) e quindi li analizzerà sui tuoi modelli (POJO) in modo che il tuo JSP possa recuperarli dal controller e fare il display. Pubblicare dati da JSP è il contrario, ho omesso qui.

Non è affatto vicino a una guida completa poiché questo argomento è piuttosto vasto e dipende fortemente dalle tue esigenze specifiche, ma i termini inclusi qui sono sufficienti per fare ulteriori ricerche (Google, lo è). Spero che questo ti dia alcune idee su come approcciare.


1
Il dominio è generalmente il livello contenente la logica aziendale. Il dominio viene di solito indicato anche come livello contenente servizi. Gli oggetti di dominio non sono semplici POJO, l'oggetto di dominio deve contenere una logica aziendale come la convalida degli argomenti e come tale. Probabilmente sarebbe meglio rinominare il layer in qualcos'altro. Il livello del repository è anche abbastanza spesso usato per trasferire dati da più origini ai tuoi oggetti di dominio.
Andy,

I moduli di servizio e deposito saranno anche progetti di primavera?
Glenn Van Schil,

1
@GlennVanSchil No, non devono essere progetti Spring b / c quando l'intero progetto viene creato, il livello repo / service verrà incluso nel percorso di classe. La @Autowirefunzionerà come un risultato.
Minjun Yu

@MinjunYu Grazie per la risposta chiara! Ma il tuo repository / servizio ha bisogno di una molla come dipendenza maven per le annotazioni di servizi, repository o componenti, giusto?
Glenn Van Schil

1
@GlennVanSchil Se si inseriscono tutte le dipendenze di Spring Maven nel pom.xml del modulo padre, non è necessario aggiungere dipendenze relative alla molla nei moduli figlio (moduli repo / service). Questo è solo un modo per impaginare progetti multi modulo in primavera. Lo scopo è organizzare il tuo codice. Se il tuo progetto non è così grande e non cambierà nel prossimo futuro, puoi combinare dominio, repository, servizio nello stesso modulo chiamato "core". Sembra ancora più pulito.
Minjun Yu

2

Pur concordando con la maggior parte della risposta di @ Minjun.Y, penso che sceglierei un approccio leggermente diverso al livello REST e alla pagina Web. Dalla mia lettura della tua domanda, penso che tu voglia esporre al mondo esterno sia un'interfaccia web che un'interfaccia REST. C'è poco da guadagnare leggendo i POJO dal database, trasformando i dati in JSON, quindi di nuovo in POJO per il consumo da parte dei JSP.

Preferirei che il livello di servizio esegua tutto il lavoro reale e aggiunga livelli di "presentazione" separati per l'app Web (JSP) e il controller REST. Questi sarebbero controller separati, in cui verrebbe iniettato il servizio. In alternativa, scegli solo un servizio REST e crea tutta la logica di presentazione sul lato client come da risposta precedente.

Inoltre, non sono un grande fan dei moduli Maven. Il modo in cui il nostro negozio Java implementerebbe il tuo progetto sarebbe quello di rendere le versioni regolari del livello di servizio, quindi rendere i livelli di presentazione dipendenti dall'ultima versione. C'è spazio per la discussione su questo, ma sicuramente funziona per noi. Avremmo l'interfaccia web e le interfacce REST come progetti Maven separati, poiché normalmente vivono in diversi file .war e quindi richiedono una distribuzione separata.

A proposito, rafforzerei la necessità di tenermi al passo con gli strumenti di gestione delle build e delle dipendenze. Una volta che il tuo progetto raggiunge dimensioni ragionevoli, ne hai bisogno. Strumenti gratuiti come Maven, Jenkins e Nexus rendono la gestione delle versioni meno problematica.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.