Mentre ci sono molte scuole di pensiero su questo, e certamente nessuna strada può essere definita "la strada giusta" universalmente, mentre tutte le altre sono "nel modo sbagliato" universalmente, ci sono una serie di ragioni per isolare la logica aziendale lato server e accedere a tali oggetti e servizi tramite un servizio RESTful.
La risposta breve è che si tratta principalmente di gestione del rischio, monitoraggio e miglioramento delle prestazioni.
In dettaglio:
Il motivo principale numero 1 è la sicurezza. Ai client non dovrebbe mai essere affidato il compito di inviare qualcosa di diverso dalla spazzatura al server, e mantenendo gli aspetti relativi alla sicurezza lato server, si isola il potenziale rischio di un utente canaglia che danneggia il sistema. Ricorda, Javascript è completamente client-side, e banalmente modificabile, quindi NON PUOI FIDARTI DELL'OUTPUT.
La ragione numero 2 è la separazione delle preoccupazioni. Il tuo programmatore javascript potrebbe non essere un esperto di sicurezza e il tuo guru della sicurezza potrebbe non essere così bravo su Javascript. Isolando la logica di business dalla logica di presentazione, si evita di superare questi problemi, dato che al javascript non sarà consentito accedere alle risorse oltre i livelli di autorizzazione e ricevere errori, la cui gestione è all'interno del previsualizzatore di script. Allo stesso modo, il responsabile della sicurezza non eseguirà il debug di Javascript per vedere come viene mantenuta la sicurezza.
Il motivo numero 3 è la prestazione. La logica aziendale può potenzialmente richiedere risorse server e database. Mantenendo tale logica isolata dagli elementi dell'interfaccia utente, è possibile ridimensionare solo quella parte dell'applicazione, rendendo molto più semplice affrontare i colli di bottiglia. Inoltre, è molto più semplice isolare quale processo aziendale sta caricando il tuo sistema oi back-end del database se i processi di business sono eseguiti sul server.
Un corollario è che spesso diversi processi aziendali utilizzano gli stessi dati e quindi è possibile implementare la memorizzazione nella cache sul lato server per ridurre il carico complessivo del sistema che potrebbe non essere possibile / sicuro per consentire l'accesso al codice lato client.
Infine, proporrei che per mantenere gli standard ACID, Business Logic abbia davvero bisogno di essere sul server. Ricordo di aver mantenuto un prodotto di fatturazione eseguito nel browser web, con solo una connessione al database del server. Se la fatturazione giornaliera (che potrebbe richiedere un'ora o più in una buona giornata!) È stata interrotta, ad esempio dal fatto che il browser è stato chiuso o si è bloccato, potrebbero essere necessarie diverse ore per risolvere il disordine creato dal database, che è stato lasciato in uno stato incoerente. Ricorda che questo comportava anche carte di credito, quindi i record di fatturazione dovevano essere controllati anche dal processore!
La logica aziendale lato server è in gran parte banale per garantire gli aggiornamenti ACID, poiché esistono framework per qualsiasi lingua per mantenere le transazioni, a livello di applicazione o di database. Se lo fai tramite più aggiornamenti da un client web ... a un certo punto otterrai uno stato incoerente e probabilmente avrà conseguenze sulla tua applicazione.
Mentre può essere allettante pensare ai servizi RESTful semplicemente come un modo per accedere al database, non dovresti cadere in questa trappola, poiché è una buona ricetta per il disastro. Il modello di oggetto che esponi tramite un servizio RESTful può essere correlato al tuo database, ma in realtà dovrebbe incapsulare la tua logica di business invece di utilizzarlo come motore CRUD.