(j'avais fait un brouillon avant la réponse de Sephi mais j'ai fini mon épisode avant de poster, donc il y aura des redites)
Ici par API on entend simplement que le serveur ne te renvoie que des données, par exemple du JSON ou du XML, et c'est ton code javascript seul qui se charge de présenter ces donneés, donc de gérer le HTML.
Ça ne change rien au fait que le code serveur est le tien, tu fais ce que tu veux des requêtes que tu reçois. Simplement tu utilises un format de données générique plutôt que de devoir traiter tes données différemment ce que tu veux afficher. Ça simplifie pas mal la partie serveur et permet d'isoler les choses.
Le javascript devient plus indépendant et tu peux mettre des event handlers où tu veux directement avec des fonctions au lieu de mettre des données un peut partout dans le DOM. Le DOM n'est pas un espace de stockage pour l'état.
En contrepartie ton javascript se complexifie pas mal. Vue n'est pas ma tasse de thé mais j'ai pratiqué pas mal et ça fonctionnera bien.
Pour un jeu, je n'utiliserais pas REST, mais RPC, et comme Sephi je le fais au travers d'un websocket car j'ai des processus qui prennent un certain temps sur le serveur (par exemple 30 secondes, le temps de construire un bâtiment) et c'est plus simple d'envoyer un nouvel état depuis le serveur plutôt que de gérer aussi des timers côté client pour rafraîchir la vue. Mais ça nécessite forcément une architecture serveur plus conséquente. Ce n'est cependant pas indispensable, surtout si tu (re)débutes et que tu pars logiquement sur un projet plutôt simple.
Citation :Mais il est probablement possible de sécuriser pour ne permettre que des requêtes internes.
Ici par API on entend simplement que le serveur ne te renvoie que des données, par exemple du JSON ou du XML, et c'est ton code javascript seul qui se charge de présenter ces donneés, donc de gérer le HTML.
Ça ne change rien au fait que le code serveur est le tien, tu fais ce que tu veux des requêtes que tu reçois. Simplement tu utilises un format de données générique plutôt que de devoir traiter tes données différemment ce que tu veux afficher. Ça simplifie pas mal la partie serveur et permet d'isoler les choses.
Le javascript devient plus indépendant et tu peux mettre des event handlers où tu veux directement avec des fonctions au lieu de mettre des données un peut partout dans le DOM. Le DOM n'est pas un espace de stockage pour l'état.
En contrepartie ton javascript se complexifie pas mal. Vue n'est pas ma tasse de thé mais j'ai pratiqué pas mal et ça fonctionnera bien.
Pour un jeu, je n'utiliserais pas REST, mais RPC, et comme Sephi je le fais au travers d'un websocket car j'ai des processus qui prennent un certain temps sur le serveur (par exemple 30 secondes, le temps de construire un bâtiment) et c'est plus simple d'envoyer un nouvel état depuis le serveur plutôt que de gérer aussi des timers côté client pour rafraîchir la vue. Mais ça nécessite forcément une architecture serveur plus conséquente. Ce n'est cependant pas indispensable, surtout si tu (re)débutes et que tu pars logiquement sur un projet plutôt simple.