In generale, è accettabile per un'applicazione Web MVC utilizzare gli endpoint REST per il suo livello di accesso ai dati? Mi rendo conto che ciò renderebbe praticamente ogni richiesta richiesta 2 e che non sembra piacevole. Quello che non so è se questo è un approccio "valido" o comunemente usato.
is it acceptable for a web MVC application to use REST endpoints for it's data access layer?
Sì, perché no? Non appena puoi mantenere l'API REST senza stato . Il frontend (MVC) può essere di stato se necessario. Questo è in qualche modo il tipo di applicazioni web che abbiamo implementato durante l'ultimo decennio.
Indipendentemente dal framework, per me, la chiave è mantenere separato il frontend (MVC) dal backend (API). E quando dico separato, dico totalmente separato. Se possibile come diverse applicazioni. O almeno, come moduli diversi.
Se si prevede di utilizzare Spring Boot + Spring MVC, questo è probabilmente l'approccio nella propria roadmap.
È importante qui mantenere separati anche i contesti web. Possiamo ottenere questo metodo con RequestMappings
Contesto web MVC:
@RequestMapping("/myapp/web")
@RequestMapping("/myapp/web/home")
...
Contesto web dell'API
@RequestMapping("/myapp/api")
@RequestMapping("/myapp/api/users")
...
O letteralmente con due diversi contesti web .
Contesto web MVC:
@RequestMapping("/my-mvc-app/...")
...
Contesto web dell'API
@RequestMapping("/my-rest-api/...")
...
Perché i contesti web separati? Trovo che la sicurezza sia più facile da configurare in questo modo. Inoltre, potremmo decidere di lavorare con i cookie in uno dei contesti, entrambi o nessuno.
Una volta definiti i contesti web (o sottocontesti) è il momento della sicurezza. Per più configurazioni di sicurezza, dai un'occhiata qui . Ricordati di rendere apolidi la sicurezza dell'API.
Pro: Spring ti offre tutto ciò di cui hai bisogno per il MVC. Devi appena reinventare la ruota. Dalla sicurezza per visualizzare gli esportatori, Spring farà tutto il lavoro duro per te.
Probabilmente è l'approccio con cui abbiamo più familiarità (in generale per quelli che provengono dal tradizionale Java EE)
Contro: Spring MVC consente di inviare il modello accanto alla vista nella risposta http. Pertanto, le chiamate all'API per il rendering della vista diventano (quasi) inutili. L'utilizzo dell'API è ridotto a chiamate asincrone per migliorare la visualizzazione, con l'inconveniente della sessione MVC (stateful) che rimane inconsapevole delle modifiche prodotte dall'API. Quindi la vista dovrebbe aggiornare lo stato del MVC. Come? Ricaricare la pagina. Infine, la doppia sicurezza. Ti ricordi che API e MVC hanno diverse configurazioni di sicurezza? A causa dell'API e della sua sicurezza sono senza stato, la sessione MVC non ti concede l'accesso all'API: -).
Nota: qualcuno potrebbe dire che l'API e la sicurezza non devono essere apolidi. Certo, se tutto è stato statico rendiamo le cose più facili ... Nel breve termine
Questo è probabilmente l'approccio migliore per le API di resto. Dopotutto, è esattamente come funziona l'app mobile.
MVC è isolato nell'applicazione client. Dalla navigazione alla sicurezza (a parte la sicurezza lato server). Modelli, viste e controller anche.
Una significativa complicazione dell'approccio è di trattare con CORS .
Un trucco sta ospitando l'app client all'interno dell'applicazione Spring Boot. Posizionare l'app client (principalmente il contesto statico) in static cartella
/src/main/resources/static
Pro: Elevato grado di deocupling, che tradotto in jergon di project management significa: Facile parallelizzare gli SDLC.
Tradotto in software jergon: nessun lock-in del framework, siamo liberi di implementare MVC, MVP, MVVM o qualsiasi altro pattern, il lato server è ora più semplice e l'interazione tra server e client è meno complessa. Facile da testare Facile da ridimensionare, perché il lato server è completamente stateless.
Contro: Un intero nuovo universo di framework, strumenti, librerie e headahes ti sta aspettando. A volte ti sentirai come reinventare la ruota. Trattare con CORS è noioso. Gli errori del calcolo distribuito ti colpiscono improvvisamente in faccia come mai prima d'ora.
I realize this would make practically every request cost 2 requests and that doesn't sound nice.
Non necessariamente. Ricorda che Spring MVC (approccio # 1) ha anche "Modello" e restituire un modello nella risposta http salva tutte le chiamate API indirizzate al rendering.
What I don't know is if this is a "valid" or commonly used approach.
Non ci sono cose come:
Solo approcci (soluzioni) che soddisfano al meglio le tue esigenze, esigenze e preferenze.
Sì, è accettabile. Attualmente sto facendo un'applicazione che fa questo.
Tuttavia, dovresti avere una buona ragione per farlo. A mio parere, è preferibile che l'applicazione MVC non utilizzi un punto finale di riposo per i dati. L'uso di un punto finale di riposo riduce le prestazioni e aumenta la complessità tecnica.
Sebbene l'utilizzo di un endpoint di riposo riduca le prestazioni, dovrebbe essere trascurabile se entrambi i server si trovano nella stessa rete fisica. Penso che il costo maggiore sia la codifica e la manutenzione aggiuntive necessarie.
Esistono tre modi principali per progettare l'API dei tuoi dati di riposo:
I modelli di output sono basati direttamente sullo schema del DB
I modelli di output sono basati sulle entità aziendali (le proprietà persistenti del modello di comportamento logico)
I modelli di output si basano sui tuoi modelli di visualizzazione (ciò che l'applicazione deve essere visualizzata)
Ti suggerirei, se segui il percorso di riposo, per evitare di basare la API dei dati sui tuoi modelli di visualizzazione (n. 3), in quanto ciò influisce negativamente sulla riutilizzabilità acquisita da un ambiente di riposo.
Ma la cosa più importante da evitare è avere un ambito di output ambiguo ... vale a dire, decidere se la tua API eseguirà 1, 2 o 3, quindi attenersi ad essa!
Leggi altre domande sui tag rest web-applications