Remarques

Les vitesses affichées ici doivent être prises avec des pincettes ! Elle ne sont là que pour donner une idée générale de "la performance du moment" entre le client web (écrit en HTML/CSS/Javascript) et le serveur web (avec ses web-services écrits en PHP et appelés par le client web).

Ces performances dépendent en effet de nombreux facteurs comme le moteur Javascript du navigateur web utilisé, sa version et ses réglages (vous n'aurez pas les mêmes performances sur Chrome ou sur Safari), le niveau de charge du serveur web, le niveau de charge du réseau, ...

Ces mesures montrent bien que, de manière générale, il n'y a quasiment aucune différence entre un web-service PHP qui répond directement ou un web-service PHP qui, en plus, a en plus besoin de sa base de données pour effectuer son travail (s'y connecter, faire des requêtes, se déconnecter). L'essentiel du temps "perdu" se situe essentiellement a) entre le client et le serveur et b) le démarrage de l'exécution du web-service PHP (PHP8 accélère grandement cette partie avec sa précompilation du code exécuté).

Cette mesure donne néanmoins une bonne idée du nombre d'appels à la seconde qu'on peut espérer réaliser avec cette technologie (client web HTML/CSS/Javascript) AJAX (WS en PHP).

Bonnes pratiques

L'idéal c'est d'essayer de toujours respecter la bonne pratique suivante :

Une action utilisateur un seul appel de web-service Une action utilisateur (N°1 sur l'image) un seul appel de web-service (N°4 sur l'image)

Car cette approche a de nombreux impacts positifs, tant sur le client que sur le serveur !

Client-web :

• L'écriture du client web devient plus simple !
  Avec cette approche, plus besoin d'une foison d'appels à différents web-services pour faire le travail. Pour chaque besoin du client web, il y aura une méthode parfaitement adaptée aux besoins tant au niveau de la fonctionnalité fournie que des informations retournées utiles ainsi que de leur format idéal pour les besoins du client web.

Expérience utilisateur :

• Expérience utilisateur perçue comme très rapide voire instantanée
  Chaque appel de web-service ne dure qu'une fraction de seconde. En appliquant ce principe général (1 action utilisateur = 1 appel ws), l'utilisateur aura une expérience d'utilisation très favorable avec cette approche et percevra la fonctionnalité fournie comme "instantanée" (puisqu'il ne faudra de manière générale qu'un seul appel de nécessaire pour chacune des intéractions utilisateur avec l'ihm).

Web-services :

• évite la réalisation de fonctionnalités inutiles
  Cette approche part des besoins du client web et de toutes les intéractions utilisateur prévues (d'éventuelles autres fonctionnalités ne sont pas nécessaires et donc inutilisées !).
• leur réalisation sera facilitée !
  La focalisation sur le besoin du côté du client va guider la réflexion tant au niveau fonctionnel qu'au niveau du retour souhaité pour cette méthode à réaliser. Tout particulièrement au niveau du format idéal de ce retour pour qu'il soit le plus utile et le plus facile à utiliser par le client dans ce contexte d'utilisation-là.
• évite de créer toute une ribambelle de fonctionnalités inutiles côté serveur
  La tendance, le "piège" dans lequel on tombe facilement est de créer, sujet par sujet, des méthodes CRUD côté serveur. Cela représente vite beaucoup de travail qui, une fois fait ... ne résoudra encore rien des besoins du client web ! Donc si on ne fait pas attention, on va se retrouver avec tout un tas de méthodes côté serveur qui ne seront pas forcément utile au client web. Pire, plutôt que d'avoir LA méthode qui répond parfaitement à ses besoins le client web devra du coup appeler plusieurs web-services pour réaliser ses opérations métier souhaitées, le client web finira donc par contenir lui aussi une partie de cette logique métier, ce qui n'est vraiment pas bien. Sans parler de la gestion des cas d'erreurs bien plus complexe (voire impossible à réaliser correctement) côté client web. Pire, sans l'application de ce principe il n'y aura pas de gestion propre et correcte des comportements souhaités face à une utilisation simultanée par plusieurs utilisateurs (gestion du verrouillage et des transactions).

Architecture et sécurité :

• Logique métier côté serveur
  Avec l'application de ce principe, la logique métier se trouvera davantage regroupée là où elle devrait se trouver (du côté serveur).
• Moins de duplication de traitements côté client et côté serveur
  En effet, si on imagine une application qui doit "empêcher" de pouvoir supprimer un utilisateur si celui-ci a encore des commandes actives, faire ces vérifications du côté du client web uniquement (et pas du côté serveur) ne serait pas une bonne idée car cela permettrait de quand même supprimer l'utilisateur en appelant le web-service de suppression d'utilisateur.
  Le faire des deux côtés (dans le client web et dans les web-services) serait également une mauvaise idée car on dupliquerait des traitements et des tests. La logique métier (c'est bien de ça qu'il s'agit dans cet exemple) se retrouverait implémentée à plusieurs endroit et toute évolution de celle-ci impliquerait des modifications à plusieurs endroits, avec les risques d'erreurs qui vont avec.
• Moins de vérifications côté client et côté serveur
  Similaire au point précédent. Avec ce principe mis en pratique, (de manière générale) l'application web disposera d'une méthode spécifique pour gérer la problématique métier de chaque action utilisateur. Ainsi, le client web n'aura généralement qu'une méthode à appeler et ensuite deux cas de figure à gérer : une information retournée indiquant le succès de l'opération (et donc aussi les information utiles à l'application web dans ce cas de figure) ou indiquant une erreur (et donc aussi l'erreur spécifique que l'application web doit afficher à l'utilisateur). Beaucoup plus simple à réaliser côté client web.