Architecture(s) et application(s) Web

Architecture(s) et
application(s) Web

CSC4101 - Protocole HTTP, serveur Web et invocation programmes

20/09/2024

Récap séquences précédentes

Introduction architecture 3 couches
Langage PHP
Couches accès aux données avec Doctrine
Appli Todo (et Mini-Allociné) en ligne de commande / console
Démarrage du projet

Plan de la séance

Fonctionnement des serveurs Web
Invocation du code applicatif
Outils HTTP du développeur Web

Role du serveur HTTP

Comprendre les requêtes HTTP des clients
- URL (http(s)://example.com/hello)
- Verbe/méthode/action (GET, POST, …)
- En-têtes
- Données transmises
Construire la réponse
- Servir des documents
- Ou exécuter des programmes
Renvoyer une réponse au client (HTML, etc.)

Mais aussi

Vérifier la sécurité
Gérer les performances
…

Exemples

Apache
Nginx
PaaS (Platform as a Service) prêt à l’emploi sur un Cloud, par ex. platform.sh

Démo

Apache dans une VM

Programmes / Applications

Modèle d’exécution

Attendre des requêtes
Quand une requête HTTP particulière survient, déclencher votre programme
recommencer

Si plusieurs requêtes de plusieurs clients différents au même moment, même programme exécuté plusieurs fois en parallèle

Traitement typique d’une requête

Le serveur Web invoque un programme
Programme s’exécute sur « plate-forme » : langage, etc.
Programme fournit sortie au format HTML (en général) : transmise « telle-quelle »

Multi-tâches

Concurrence d’exécution sur le serveur

Concurrence d’exécution sur le serveur

Concurrence d’exécution sur le serveur

Technologies d’invocation d’un programme

Différentes façons d’appeler un programme
Exécution :
- Directe sur le système d’exploitation : CGI (Common Gateway Interface)
ou
- Dans le contexte d’un serveur d’applications
  - Un module au sein du serveur Web
  - Un serveur d’application séparé

CGI (Common Gateway Interface)

Requête sur une URL invoque une exécution d’un processus sur l’OS : shell script, exécutable compilé, script (Perl, Python, …)
Point d’entrée du programme unique : programmation impérative « classique »
Problèmes :
- lourdeur de l’invocation d’un nouveau processus système à chaque requête
- gestion de session difficile
- sécurité : celle de l’OS

Obsolète !

« Au sein » du serveur HTTP

Le serveur HTTP « intègre » des fonctionnalités pour développer des applications (via des « plugins »):
- Langage de programmation « embarqué » (PHP, Python, …)
- Gestion « native » de HTTP
- Génération « facile » de HTML, etc.
Exécution dans des threads dédiées (plus efficace que des processus à invoquer)
Transfert des données immédiat : en mémoire, sans passer par l’OS

Serveur d’applications séparé

Le serveur Web gère la charge HTTP et fournit des documents statiques (CSS, images, etc.)
Un (ou plusieurs) serveur(s) d’applications gère(nt) l’exécution des réponses dynamiques aux requêtes
Le serveur HTTP et les serveurs d’application sont connectés de façon efficace (si possible)
Le serveur d’application gère des sessions
Rend indépendantes partie statique et partie dynamique : s’adapter à la charge plus ou moins dynamiquement.

Exemple : programmes Web en PHP

Bibliothèques pour spécificités HTTP
Facile à tester (?)
Très populaire pour déploiement chez des hébergeurs
Très permissif sur le style de programmation
Conserve des mécanismes très proches de la façon d’écrire les programmes en scripts CGI
Serveur d’exécution PHP dédié (PHP-FPM)

C’est le langage qu’on va utiliser dans ce cours.

On utilisera la plate-forme PHP fortement en TPs et Hors-Présentiel, mais pas le serveur d’applications PHP-FPM.

On utilisera par contre l’environnement de développement et de mise au point fourni par le framework Symfony, qui permet un mode de fonctionnement un peu différent pour tester des programmes PHP. Ce ne sera pas un serveur Web qui invoquera des programmes PHP, mais on utilisera l’interpréteur PHP pour qu’il fasse fonctionner un serveur HTTP basique en amont des programmes. Cela renverse un peu la logique : c’est l’interpréteur PHP qui démarre un serveur Web, et non l’inverse.

Par contre, en environnement de production, une fois l’application développée et déployée, Symfony s’exécuterait derrière PHP-FPM, de façon standard.

Démo

PHP « derrière » Apache, avec php-fpm

Déployer

Serveur classique et recopie du code

Exemple: avec FTP sur serveur Apache + PHP + SGBD

Automatisation sur PaaS avec Git

Git push vers un hébergement Cloud Platform as a Service

Exemple: avec commande symfony CLI sur platform.sh

Le principe est ici de sauvegarder les modifications du code dans Git, puis de déployer une version automatiquement à partir de ce référentiel Git.

On automatise ainsi la sauvegarde d’une version bien identifiée, sans possibilité de modification côté serveur sans être repassé par la phase de contrôle qualité au niveau développement.

Ce mécanisme, utilisé dans l’approche DevOps permet d’automatiser et d’améliorer la qualité.

Les besoins côté serveur (version du langage, type de SGBD, dimensionnement, etc.) peuvent même être décrits dans des fichiers de configuration dans le code source.

Cette solution, illustrée ici avec la plate-forme cloud de platform.sh et Symfony fonctionne de façon similaire à nombre d’autres plateformes PaaS (Platform as a Service) sur le Cloud.

La plate-forme de développement et celle de déploiement sont gérées de façon cohérente comme un tout intégré, disponible sur le Cloud. https://fr.wikipedia.org/wiki/Plate-forme_en_tant_que_service

Les plate-formes Cloud liées au développement d’applications ne sont pas détaillées dans le cadre de ce cours.

</serveur>

Plan de la séance

Fonctionnement des serveurs Web
Invocation du code applicatif
Outils HTTP du développeur Web

Concevoir les programmes

Modèle de programmation événementielle :

définir des chemins d’URL, et autres éléments de contexte qui déclencheront l’exécution du code
écrire les différents morceaux de code qui doivent s’exécuter quand les requêtes arrivent sur chacun de ces chemins

Contexte d’invocation

Données transmises au serveur Web
via la requête HTTP :

URL
Arguments (URL-encoded)

En-têtes
Cookies

Données
contenu (payload) de la requête (ex. données de formulaires pour un POST)

Le choix du programme à invoquer est déterminé par une combinaison d’éléments (a minima via le chemin dans l’URL)
- La configuration du serveur détermine les règles à appliquer

Invocation des programmes

Le serveur Web peut filtrer les données reçues dans la requête
Il invoque un « processus » ou l’exécution d’une fonction sur l’API d’un module
Il transmet les données au programme
- arguments d’un processus (CGI)
- variables d’environnement (CGI)
- paramètres des fonctions des APIs, ou variables du langage de programmation (module intégré)

Résultats d’exécution

Statut d’un programme :
- Code de retour système (exécution d’un processus POSIX) :
  - 0 ou != 0
Résultats :
- Sortie standard du programme
- Erreur standard ?

Conversion pour HTTP

Construction de la Réponse HTTP

Code de retour -> Code de statut

`0`	⇒	`200`
`!= 0`	⇒	`5xx`

Sorties
- Standard (stdout) telle-quelle dans réponse HTTP : attention au format
  - Headers : succès, échecs, redirections, …
    - Cookies : sessions
  - Ligne vide
  - Contenu du document :
    - HTML
    - Autres formats (APIs : JSON, …)
- Erreur standard (stderr) : dans les logs du serveur ?

La plate-forme du langage peut intégrer la gestion de la génération de la réponse, sous forme de code de statut HTTP et de messages.

Pour mémoire, on a vu précédemment le format attendu pour les réponses HTTP, que la sortie standard doit donc respecter.

Attention donc à la façon dont est générée la sortie du programme. Si on mélange l’affichage des en-têtes et du message sans respecter le format attendu, les en-têtes seront ignorés par le client HTTP. C’est particulièrement sensible si on affiche des traces de mise au point avec des print sur la sortie standard, qui risquent d’être ignorés par le client HTTP, s’ils apparaissent dans les en-têtes.

Le PHP « basique » pose un certain nombre de problèmes de ce type pour les programmeurs, qui seront résolus avec un framework comme Symfony.

Serveur HTTP intégré à PHP

Démarrage :
```
php -S localhost:8000 -t public/  
```
Exécution script PHP demandé dans la requête, si présent dans public/, (ou par défaut, par public/index.php)

Exemples :

URL	Programme	Args
`http://localhost:8000/test.php`	`public/test.php`
`http://localhost:8000/test.php?hello`	`public/test.php`	`hello`
`http://localhost:8000/`	`public/index.php`
`http://localhost:8000/hello`	`public/index.php`	`hello`
`http://localhost:8000/index.php?hello`	`public/index.php`	`hello`

Interface HTTP moderne, en Objet

Appel de méthode

Objets : instances de classes (encapsulent un état)
Méthodes : récepteurs de messages

  class Application {
      public run() {
          //...
          $command = new ListTodosCommand();
          $res = $command->execute();

Figure 1 : « Invocation d’une méthode, en diagramme de séquence UML »

Modèle de programmation événementielle

Identique dans beaucoup de systèmes de programmation d’interfaces (GUI, HTTP, …) :

objets gestionnaires d’interface
méthodes activées par des événements

Réception d’une requête HTTP => appel de méthode

Contrôleurs HTTP

Appel de méthodes dans une classe conçue pour gérer des actions (HTTP) sur des ressources (Web)

Classe contrôleur (Controller)
« écoute » des événements : requêtes HTTP sur des ressources particulières propres à cette classe
gère les actions spécifiques à effectuer (et délègue au reste du code)

Patron de conception Model, Vue, Controller (MVC)

Programmer les méthodes d’un contrôleur

Le programmeur n’écrit pas le point d’entrée index.php
Le framework fournit un composant offrant des fonctions de routage : décodage du contexte HTTP pour invoquer la bonne méthode de la bonne classe
Le programmeur n’a plus qu’à écrire des méthodes dans une classe PHP : programmation événementielle dans un contexte objet

URLs « lisibles »

Aiguillage des requêtes :

URLs sans extension .php
Tout est géré par index.php, qui passe la main au routeur

URL	Programme	Args
`http://localhost:8000/test.php`	404
`http://localhost:8000/`	`public/index.php`	NULL
`http://localhost:8000/hello`	`public/index.php`	`hello`
`http://localhost:8000/blah/plop`	`public/index.php`	`blah/plop`

Rôle du kernel Symfony

Faire la conversion entre le mode d’invocation classique de PHP, hérité des CGI d’origine, et le mode objet moderne.

Le programmeur Symfony n’a plus qu’à s’occuper :

déclarer le routage
coder les classes contrôleurs

Routeurs et contrôleurs Symfony

Routage

Le programmeur associe :
- schéma de chemin d’URL
- méthode d’une classe PHP « Contrôleur », à invoquer au traitement d’une requête
Le composant « Routeur » réalise les appels vers les bonnes méthodes

Exemple `HomeController`

src/Controller/HomeController.php

Gère : http://localhost:8000/
Classe PHP HomeController
- Méthode indexAction()
Route :

Chemin	Nom	Args
`/`	`home`

Exemple `TodoController`

src/Controller/TodoController.php

Gère :
- http://localhost:8000/todo/
- http://localhost:8000/todo/42
Classe TodoController
- Méthodes :
  - listAction()
  - showAction(id)
Routes :

Chemin	Nom	Args
`/todo/`	`todo_list`
`/todo/{id}`	`todo_show`	`id`

Méthodes gestionnaires de requêtes

Méta-données en attributs PHP 8

class TodoController extends Controller
{
    /**
     * Finds and displays a todo entity.
     */
    #[
        Route('/todo/{id}', name: 'todo_show',
              requirements: ['id' => '\d+'], methods: ['GET'])
    ]
    public function showAction(Todo $todo): Response
    {
        return ...;
    }
    //...
}

</invocation_code>

Exécution éphémère

Temps de vie du code :

Requête entrante : Routage vers méthode Contrôleur
1. Chargement données depuis base (et/ou session)
2. Traitements
3. Sauvegarde en base (et/ou session)
Envoi Réponse
Mort

Répété à chaque requête

Take away

serveur HTTP
invocation des programmes qui génèrent du HTML
programmation événementielle
routage + controleurs Symfony

Ensuite…

Séance TP n°4

Découverte Contrôleur Web Symfony, sur ToDo
Ajout Contrôleurs Web dans projet

Copyright

Document propriété de ses auteurs et de Télécom SudParis (sauf exceptions explicitement mentionnées).
Réservé à l’utilisation pour la formation initiale à Télécom SudParis.