Mentre ci sono molte scuole di pensiero su questo, e certamente nessun modo può essere definito "il modo giusto" universalmente, mentre tutti gli altri sono "il modo sbagliato" universalmente, ci sono una serie di ragioni per isolare la logica aziendale sul lato server e accedere a tali oggetti e servizi tramite un servizio RESTful.
La risposta breve è che riguarda principalmente la gestione del rischio e il monitoraggio e il miglioramento delle prestazioni.
In dettaglio:
Il motivo principale numero 1 è la sicurezza. I clienti non devono mai avere la certezza di inviare al server qualcosa di diverso dall'immondizia e, mantenendo gli aspetti di sicurezza sul lato server, isolano il potenziale rischio che un utente non autorizzato danneggi il sistema. Ricorda, Javascript è completamente lato client e banalmente modificabile, quindi NON PUOI FIDARTI DELL'USCITA.
Il motivo 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 con Javascript. Isolando la logica di business dalla logica di presentazione, si evita di superare queste preoccupazioni, poiché il javascript non sarà autorizzato ad accedere alle risorse oltre i suoi livelli di autorizzazione e riceveranno errori, la cui gestione è nell'ambito del programmatore di script. Allo stesso modo, il ragazzo 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 per server e database. Mantenendo tale logica isolata dagli elementi dell'interfaccia utente, è quindi 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 i back-end del sistema o del database se i processi aziendali vengono eseguiti sul server.
Un corollario qui è che spesso diversi processi aziendali useranno 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, al fine di mantenere gli standard ACID, Business Logic ha davvero bisogno di essere sul server. Ricordo di aver gestito un prodotto di fatturazione eseguito nel browser Web, con solo una connessione al database al server. Se la fatturazione giornaliera (che potrebbe richiedere un'ora o più in una buona giornata!) Fosse interrotta, ad esempio, in caso di chiusura o arresto anomalo del browser, potrebbero essere necessarie diverse ore per risolvere il disordine che ha creato sul database, che è stato lasciato in uno stato incoerente. Ricorda, ciò implicava anche carte di credito, quindi anche i record di fatturazione dovevano essere controllati con il processore!
La logica aziendale lato server è per lo più banale per garantire gli aggiornamenti ACID, in quanto esistono framework per qualsiasi lingua per mantenere le transazioni, a livello di applicazione o di database. Se lo stai facendo tramite più aggiornamenti da un client Web ... a un certo punto otterrai uno stato incoerente e probabilmente influenzerà la tua applicazione.
Mentre può essere allettante pensare ai servizi RESTful come semplicemente un modo per accedere al database, non dovresti cadere in questa trappola, poiché è una buona ricetta per il disastro. Il modello a oggetti che esponi tramite un servizio RESTful può essere correlato al tuo database, ma dovrebbe davvero incapsulare la tua logica aziendale invece di usarlo come motore CRUD.