Si bien hay muchas escuelas de pensamiento sobre esto, y ciertamente ninguna forma puede llamarse "la forma correcta" universalmente, mientras que todas las demás son "la forma incorrecta" universalmente, hay una serie de razones para aislar la lógica empresarial en el lado del servidor , y acceder a esos objetos y servicios a través de un servicio RESTful.
La respuesta breve es que se trata principalmente de la gestión de riesgos y el monitoreo y mejora del rendimiento.
En detalle:
La razón principal número 1 es la seguridad. Nunca se debe confiar en los clientes para que envíen otra cosa que no sea basura al servidor, y al mantener los aspectos de seguridad del lado del servidor, aísla el riesgo potencial de que un usuario no autorizado dañe su sistema. Recuerde, Javascript es completamente del lado del cliente, y trivialmente modificable, por lo que NO PUEDE CONFIAR EN LA SALIDA.
La razón número 2 es la separación de las preocupaciones. Es posible que su programador de JavaScript no sea un experto en seguridad y que su gurú de la seguridad no sea tan bueno en Javascript. Al aislar la lógica de negocios de la lógica de presentación, evita cruzar estas preocupaciones, ya que no se permitirá que javascript acceda a los recursos más allá de sus niveles de permiso, y se le darán errores, cuyo manejo está dentro de la versión anterior del Script Programmer. Del mismo modo, el tipo de seguridad no depurará Javascript para ver cómo se mantiene la seguridad.
La razón número 3 es el rendimiento. La lógica empresarial puede ser potencialmente exigente con los recursos del servidor y la base de datos. Al mantener esa lógica aislada de sus elementos de la interfaz de usuario, puede escalar solo esa parte de su aplicación, lo que hace que sea mucho más fácil abordar los cuellos de botella. Además, es mucho más fácil aislar qué proceso empresarial está cargando el sistema o la base de datos de la base de datos si los procesos empresariales se ejecutan en el servidor.
Un corolario aquí es que, a menudo, varios procesos empresariales utilizarán los mismos datos, por lo que puede implementar el almacenamiento en caché en el lado del servidor para reducir la carga general del sistema que podría no ser posible / seguro para dar acceso a los códigos del lado de los clientes.
Finalmente, propondría que para mantener los estándares ACID, Business Logic realmente necesita estar en el servidor. Recuerdo haber mantenido un producto de facturación que se ejecutaba en el navegador web, con solo una conexión de base de datos al servidor. Si la facturación diaria (¡que podría tomar una hora o más en un buen día!) Se interrumpe, por ejemplo, cuando el navegador se cierra o falla, podría tomar varias horas resolver el desastre que causó en la base de datos, que quedó en un estado inconsistente Recuerde, esto también implicaba tarjetas de crédito, por lo que los registros de facturación también debían verificarse con el procesador.
La lógica empresarial del lado del servidor es en su mayoría trivial para garantizar actualizaciones de ACID, ya que existen marcos para cualquier lenguaje para mantener las transacciones, ya sea a nivel de aplicación o de base de datos. Si está haciendo esto a través de múltiples actualizaciones desde un cliente web ... obtendrá un estado inconsistente en algún momento, y es probable que afecte a su aplicación.
Si bien puede ser tentador pensar en los servicios RESTful como una simple forma de acceder a la base de datos, no debe caer en esta trampa, ya que es una buena receta para el desastre. El modelo de objetos que expone a través de un servicio RESTful puede estar relacionado con su base de datos, pero realmente debería encapsular su lógica empresarial en lugar de simplemente usarlo como un motor CRUD.