Bien qu'il existe de nombreuses écoles de pensée à ce sujet, et certainement aucune façon ne peut être qualifiée de "la bonne façon" universellement, tandis que toutes les autres sont "de la mauvaise façon" universellement, il existe un certain nombre de raisons pour isoler la logique métier côté serveur. et accédez à ces objets et services via un service RESTful.
La réponse courte est qu'il s'agit principalement de gestion des risques, de suivi et d'amélioration des performances.
En détail:
La raison primordiale numéro 1 est la sécurité. Il ne faut jamais faire confiance aux clients pour soumettre autre chose que des ordures au serveur, et en gardant les aspects de sécurité côté serveur, vous isolez le risque potentiel qu'un utilisateur voyou endommage votre système. Rappelez-vous, Javascript est complètement côté client et peut être modifié de manière triviale, vous ne pouvez donc PAS FAIRE CONFIANCE À LA SORTIE.
La raison numéro 2 est la séparation des préoccupations. Votre programmeur javascript n'est peut-être pas un expert en sécurité, et votre gourou de la sécurité n'est peut-être pas si bon en Javascript. En isolant la logique métier de la logique de présentation, vous évitez de traverser ces problèmes, car le javascript ne sera pas autorisé à accéder aux ressources au-delà de ses niveaux d'autorisation, et recevra des erreurs, dont la gestion est à la portée du programmeur de script. De même, le responsable de la sécurité ne déboguera pas Javascript pour voir comment la sécurité est maintenue.
La raison numéro 3 est la performance. La logique métier peut potentiellement exiger des ressources de serveur et de base de données. En gardant cette logique isolée de vos éléments d'interface utilisateur, vous pouvez ensuite mettre à l'échelle uniquement cette partie de votre application, ce qui facilite d'autant plus la résolution des goulots d'étranglement. De plus, il est beaucoup plus facile d'isoler le processus métier qui charge votre système ou votre base de données si les processus métier sont exécutés sur le serveur.
Un corollaire ici est que, souvent, plusieurs processus métier utilisent les mêmes données, et vous pouvez donc implémenter la mise en cache côté serveur pour réduire la charge globale du système qui pourrait ne pas être possible / sécurisé pour permettre aux clients d'accéder au code côté.
Enfin, je proposerais que pour maintenir les normes ACID, Business Logic ait vraiment besoin d'être sur le serveur. Je me souviens d'avoir conservé un produit de facturation qui fonctionnait dans le navigateur Web, avec seulement une connexion de base de données au serveur. Si la facturation quotidienne (qui pouvait prendre une heure ou plus par une bonne journée!) Était interrompue, par exemple, en fermant ou en plantant le navigateur, cela pourrait prendre plusieurs heures pour régler le gâchis qu'elle faisait de la base de données, qui a été laissé dans un état incohérent. N'oubliez pas que cela impliquait également les cartes de crédit, de sorte que les relevés de facturation devaient également être vérifiés par le processeur!
La logique métier côté serveur est généralement triviale pour assurer les mises à jour ACID, car il existe des cadres pour n'importe quelle langue pour gérer les transactions, au niveau de l'application ou de la base de données. Si vous le faites via plusieurs mises à jour à partir d'un client Web ... vous allez avoir un état incohérent à un moment donné, et cela va probablement affecter votre application.
Bien qu'il puisse être tentant de considérer les services RESTful comme un simple moyen d'accéder à la base de données, vous ne devriez pas tomber dans ce piège, car c'est une bonne recette pour un désastre. Le modèle d'objet que vous exposez via un service RESTful peut être lié à votre base de données, mais devrait vraiment encapsuler votre logique métier au lieu de simplement l'utiliser comme moteur CRUD.