C'est une approche à base de webservice plutôt que de génération dynamique de page HTML.
C'est plutôt orienté pour faire des applications ou des services web, par opposition aux sites web qui sont efficaces pour afficher de l'information statique aux utilisateurs: site web de la boite, blog, etc.
On va prendre un cas d'utilisation simple: afficher dans une page la liste des courses stockée dans une BD.
Dans ce que tu appelles la "vieille méthode", tu as une page index.php dont le code php exécuté coté serveur va chercher la liste des courses en faisant la requête SQL directement dans la BD, parse le résultat et génère la page HTML correspondante avec ta liste de courses puis l'envoie au client.
Dans la "nouvelle méthode", la liste des courses est accessible sur une URL qui lui est propre et qui renvoie la liste des courses dans un tableau JSON par exemple, par exemple /api/courses/. À coté, tu as par exemple une page HTML statique mais contenant du code javascript, le javascript va appeler l'API /api/courses au chargement de la page, parser le résultat et générer le tableau en modifiant le DOM de la page.
Et dans cette approche, tu peux avoir le webservice hébergé sur un serveur, et la page HTML statique hébergée sur un autre serveur type apache qui ne servira que du statique et sera sous stéroïdes pour servir des simples fichiers plats.
Je vais pas te dire qu'une approche est mieux que l'autre, c'est pas le sujet, et puis ca dépend des cas.
Dans la "vieille méthode", on centralise la gestion des données et son affichage au même endroit, et ca peut limiter tes possibilités d'extension.
Dans l'approche par webservice, on a une distinction plus forte entre les données et l'affichage, ca permet d'accéder aux données via d'autres clients (application mobile, script shell, autre application web, une page PHP, etc.) sans avoir à changer le backend ou rajouter un nouveau backend à chaque fois.
Ca permet aussi de faire évoluer le backend et le front-end de manière distincte en limitant les impacts, voire de rajouter des fonctionnalités au backend dont on sait qu'elles ne seront pas utilisées par tous les clients, mais sans avoir à patcher les clients qui n'utiliseront pas les nouvelles fonctionnalités.
Mais rien n'est absolu et les deux approches sont plus complémentaires qu'autre chose, celui qui dira que PHP va mourir parce que SOAP/REST/Whatever va devenir la norme, je lui réponds que PHP était là bien avant sa naissance et sera encore là bien après sa mort.
De plus, si je mets des guillemets à "ancienne méthode", c'est parce que l'approche par webservice n'a pas réinventé l'eau chaude non plus. Entre une page html statique qui appelle une API en javascript pour afficher un tableau et une page php qui fait un require() pour appeler le module php qui va afficher le même tableau, l'approche n'est pas fondamentalement différente.
L'approche par webservice n'est pas magique non plus, c'est très facile de faire une application web qui sera lente voire inutilisable parce qu'elle fait trop d'appels à trop d'API en même temps par exemple. Ou tomber dans l'enfer des applications mal foutues par design comme expliqué dans un article pointé dans un autre journal.
[^] # Re: Cutelyst
Posté par Babelouest (site web personnel) . En réponse au journal Des nouvelles d'Ulfius, framework web en C. Évalué à 10.
C'est une approche à base de webservice plutôt que de génération dynamique de page HTML.
C'est plutôt orienté pour faire des applications ou des services web, par opposition aux sites web qui sont efficaces pour afficher de l'information statique aux utilisateurs: site web de la boite, blog, etc.
On va prendre un cas d'utilisation simple: afficher dans une page la liste des courses stockée dans une BD.
Dans ce que tu appelles la "vieille méthode", tu as une page
index.phpdont le code php exécuté coté serveur va chercher la liste des courses en faisant la requête SQL directement dans la BD, parse le résultat et génère la page HTML correspondante avec ta liste de courses puis l'envoie au client.Dans la "nouvelle méthode", la liste des courses est accessible sur une URL qui lui est propre et qui renvoie la liste des courses dans un tableau JSON par exemple, par exemple
/api/courses/. À coté, tu as par exemple une page HTML statique mais contenant du code javascript, le javascript va appeler l'API/api/coursesau chargement de la page, parser le résultat et générer le tableau en modifiant le DOM de la page.Et dans cette approche, tu peux avoir le webservice hébergé sur un serveur, et la page HTML statique hébergée sur un autre serveur type apache qui ne servira que du statique et sera sous stéroïdes pour servir des simples fichiers plats.
Je vais pas te dire qu'une approche est mieux que l'autre, c'est pas le sujet, et puis ca dépend des cas.
Dans la "vieille méthode", on centralise la gestion des données et son affichage au même endroit, et ca peut limiter tes possibilités d'extension.
Dans l'approche par webservice, on a une distinction plus forte entre les données et l'affichage, ca permet d'accéder aux données via d'autres clients (application mobile, script shell, autre application web, une page PHP, etc.) sans avoir à changer le backend ou rajouter un nouveau backend à chaque fois.
Ca permet aussi de faire évoluer le backend et le front-end de manière distincte en limitant les impacts, voire de rajouter des fonctionnalités au backend dont on sait qu'elles ne seront pas utilisées par tous les clients, mais sans avoir à patcher les clients qui n'utiliseront pas les nouvelles fonctionnalités.
Mais rien n'est absolu et les deux approches sont plus complémentaires qu'autre chose, celui qui dira que PHP va mourir parce que SOAP/REST/Whatever va devenir la norme, je lui réponds que PHP était là bien avant sa naissance et sera encore là bien après sa mort.
De plus, si je mets des guillemets à "ancienne méthode", c'est parce que l'approche par webservice n'a pas réinventé l'eau chaude non plus. Entre une page html statique qui appelle une API en javascript pour afficher un tableau et une page php qui fait un
require()pour appeler le module php qui va afficher le même tableau, l'approche n'est pas fondamentalement différente.L'approche par webservice n'est pas magique non plus, c'est très facile de faire une application web qui sera lente voire inutilisable parce qu'elle fait trop d'appels à trop d'API en même temps par exemple. Ou tomber dans l'enfer des applications mal foutues par design comme expliqué dans un article pointé dans un autre journal.