Embora existam muitas escolas de pensamento sobre isso, e certamente nenhuma maneira pode ser chamada de "o caminho certo" universalmente, enquanto todas as outras são "o caminho errado" universalmente, existem várias razões para isolar a lógica de negócios no lado do servidor e acesse esses objetos e serviços por meio de um serviço RESTful.
A resposta curta é que se trata principalmente de gerenciamento de riscos, monitoramento e melhoria de desempenho.
Em detalhe:
O principal motivo número 1 é a segurança. Nunca se deve confiar nos clientes para enviar algo diferente de lixo para o servidor e, mantendo os aspectos de segurança do lado do servidor, você isola o risco potencial de um usuário não autorizado danificar seu sistema. Lembre-se de que o Javascript é totalmente do lado do cliente e é trivialmente variável, portanto você NÃO PODE CONFIAR NA SAÍDA.
A razão número 2 é a separação de preocupações. Seu programador javascript pode não ser um especialista em segurança, e seu guru da segurança pode não ser tão bom em Javascript. Ao isolar a lógica de negócios da lógica de apresentação, você evita cruzar essas preocupações, pois o javascript não terá permissão para acessar recursos além dos níveis de permissão e receberá erros, cuja manipulação está dentro da previsão do programador de scripts. Da mesma forma, o responsável pela segurança não estará depurando o Javascript para ver como a segurança é mantida.
O motivo número 3 é o desempenho. A lógica comercial pode potencialmente exigir recursos de servidor e banco de dados. Ao manter essa lógica isolada dos seus elementos de interface do usuário, você pode dimensionar apenas essa parte do seu aplicativo, facilitando muito a solução de gargalos. Além disso, é muito mais fácil isolar qual processo de negócios está carregando o sistema ou o back-end do banco de dados se os processos de negócios forem executados no servidor.
Um corolário aqui é que muitas vezes vários processos de negócios usam os mesmos dados e, portanto, você pode implementar o cache no servidor para reduzir a carga geral do sistema que pode não ser possível / segura para fornecer acesso ao código do cliente.
Por fim, proponho que, para manter os padrões ACID, a Business Logic realmente precise estar no servidor. Lembro-me de manter um produto de cobrança executado no navegador da web, com apenas uma conexão de banco de dados com o servidor. Se o faturamento diário (que pode levar uma hora ou mais em um bom dia!) For interrompido, digamos, pelo fechamento ou falha do navegador, poderá levar várias horas para resolver a bagunça que ele fez no banco de dados, que foi deixado em um estado inconsistente. Lembre-se, isso também envolvia cartões de crédito; portanto, os registros de cobrança também precisavam ser verificados no processador!
A lógica de negócios do servidor é basicamente trivial para garantir atualizações ACID, já que existem estruturas para qualquer idioma para manter transações, no nível do aplicativo ou do banco de dados. Se você estiver fazendo isso por meio de várias atualizações de um cliente da Web ... você terá um estado inconsistente em algum momento e provavelmente afetará seu aplicativo.
Embora possa ser tentador pensar nos serviços RESTful como simplesmente uma maneira de acessar o banco de dados, você não deve cair nessa armadilha, pois é uma boa receita para o desastre. O modelo de objeto que você expõe por meio de um serviço RESTful pode estar relacionado ao seu banco de dados, mas deve realmente encapsular sua lógica de negócios em vez de apenas usá-lo como um mecanismo CRUD.