Nota que Websocket ou assimilé seront souvent coupés sur un mutualisé, le choix de l'archi ira donc certainement de paire avec le choix de ton hébergement (ou à l'inverse, la contrainte d'hébergement contraindra l'archi)
Pour ma part, je considère que le web est fondamentalement basé sur la notion de "document", ce qui signifie qu'il n'y a pas lieu de séparer les API REST de la mécanique classique des pages. Dit autrement, un "site classique avec des pages HTML" c'est ni plus ni moins qu'un serveur API qui répond un document formatté en HTML. Conséquence de quoi, sur ECLERD (ou Variispace mais n'étant pas en ligne tu auras du mal à le tester), chaque point d'entrée du serveur web (endpoint) construira un modèle de données (via une procédure stockée le plus souvent) et répondra ces données formattées comme le client l'a demandé (via son head HTTP Accept, ou via le paramètre GET non standard "http-accept"). Donc typiquement, la page https://eclerd.com/map/mapcase/?id=5581 sera requêtée par le navigateur avec un Accept header "text/html" (par défaut du navigateur). Mais si un client (JS, navigateur, whatever) requête https://eclerd.com/map/mapcase/?id=5581&...ation/json (ou met son application/json dans son HTTP Accept header), alors le serveur répond les données formattées en JSON. https://eclerd.com/map/mapcase/?id=5581&...ation/json est aussi accepté (à désérialiser avec PHP). Ou encore, http-accept=application/vnd.oasis.opendocument.spreadsheet (je viens de voir que la page map/mapcase plante sur ce format, il faudra que je regarde en détail le ticket associé), que je trouve "fun" car il me servait juste à montrer (au taff) qu'on pouvait faire des exports excel instantanément et sans ajouter des tonnes de code (et si tu enregistre le fichier et que tu as open office/excel, tu devrais voir la Terre en guise d'icône de fihcier; là aussi, c'était pour le fun).
Je ne vois pas comment développer un "côté client en PHP avec Symfony"?! Et "le DOM n'est pas un espace de stockage pour l'état", ça me fait ticker, puisqu'on parle de Document Object Model (dont la définition est maintenant chez les WHATWG je crois https://dom.spec.whatwg.org/ ). Après, oui, si on veut refaire Unreal 2019 dans le DOM, ça va trimer.
Pour ma part, je considère que le web est fondamentalement basé sur la notion de "document", ce qui signifie qu'il n'y a pas lieu de séparer les API REST de la mécanique classique des pages. Dit autrement, un "site classique avec des pages HTML" c'est ni plus ni moins qu'un serveur API qui répond un document formatté en HTML. Conséquence de quoi, sur ECLERD (ou Variispace mais n'étant pas en ligne tu auras du mal à le tester), chaque point d'entrée du serveur web (endpoint) construira un modèle de données (via une procédure stockée le plus souvent) et répondra ces données formattées comme le client l'a demandé (via son head HTTP Accept, ou via le paramètre GET non standard "http-accept"). Donc typiquement, la page https://eclerd.com/map/mapcase/?id=5581 sera requêtée par le navigateur avec un Accept header "text/html" (par défaut du navigateur). Mais si un client (JS, navigateur, whatever) requête https://eclerd.com/map/mapcase/?id=5581&...ation/json (ou met son application/json dans son HTTP Accept header), alors le serveur répond les données formattées en JSON. https://eclerd.com/map/mapcase/?id=5581&...ation/json est aussi accepté (à désérialiser avec PHP). Ou encore, http-accept=application/vnd.oasis.opendocument.spreadsheet (je viens de voir que la page map/mapcase plante sur ce format, il faudra que je regarde en détail le ticket associé), que je trouve "fun" car il me servait juste à montrer (au taff) qu'on pouvait faire des exports excel instantanément et sans ajouter des tonnes de code (et si tu enregistre le fichier et que tu as open office/excel, tu devrais voir la Terre en guise d'icône de fihcier; là aussi, c'était pour le fun).
Je ne vois pas comment développer un "côté client en PHP avec Symfony"?! Et "le DOM n'est pas un espace de stockage pour l'état", ça me fait ticker, puisqu'on parle de Document Object Model (dont la définition est maintenant chez les WHATWG je crois https://dom.spec.whatwg.org/ ). Après, oui, si on veut refaire Unreal 2019 dans le DOM, ça va trimer.
Citation : Mais il est probablement possible de sécuriser pour ne permettre que des requêtes internes.Soit je n'ai pas compris, soit la réponse est non. Si un client tiers doit faire des requêtes sur ton serveur (ie: un navigateur, que ce soit avec du HTTP classique, du "REST API JSON" ou du websocket) alors il aura la main pour voir comment sont faites ces requêtes, et les triturer. Ou alors, tu veux que ton serveur fasse des requêtes vers... ton serveur? Auquel cas, c'est une énorme perte de temps d'exécution (pour rappel, en gros, c'est x10 par niveau: mémoire processeur = 1ms, accès RAM = 10ms, accès disque = 100ms, accès réseau = 1s, ok, maintenant, tout est divisé par 10, mais les ordres de grandeurs relatifs restent les mêmes). Donc en gros, à part faire plus lentement (et probablement moins sûrement) ce que tu veux faire, je ne vois pas l'intérêt d'appels serveur-serveur?