Architecture Web

Le grand merveilleux voyage d'une petite requête.

Client
1. Cliquez sur un lien ou tapez une URL dans votre navigateur.
Utilisateur
C'est vous :)
18. Votre navigateur affiche l'HTML, ou vous informe sur ce qui s'est passé.
C'est aussi ici que le JavaScript entre en action, afin d'avoir des interactions plus riches.
2. Le navigateur envoie une requête.
Navigateur
C'est l'application que vous utilisez pour naviguer sur Internet.
Exemples : Firefox, Chrome, Safari, Opera... Et aussi Internet Explorer, mais nous les développeurs, aimons le détester ;)
Navigateur
Internet
3. La requête est envoyée sur le réseau (Internet).
Requête
Elle porte les informations sur qui vous êtes et ce que vous voulez. Qui vous êtes : ça peut dépendre, mais surtout votre IP (à qui répondre), et des informations sur votre ordinateur (navigateur, taille de l'écran, d'où vous venez). Ce que vous voulez : l'URL, des paramètres, le contenu du formulaire, et tous les cookies.
Requête HTTP
17. Retour !
4. Tout un réseau d'ordinateurs, routeurs et équipements vont retrouver où votre requête devrait aller.
Réseau
L'Internet, une série de tubes ? Plutôt un maillage de serveurs, reliés par des connexions filaires, fibre, WiFi, satellite...
Réseau informatique
16. La réponse est renvoyée, de la même manière que la requête est partie.
Réponse
Vous avez posé une question, le serveur vous répond. C'est la réponse que vous attendiez, avec le contenu que vous aviez demandé.
Réponse HTTP
Serveur Web
15. Le serveur Web renvoie ce que le serveur d'application lui a donné.
5. Le serveur Web reçoit la requête, et voit s'il peut lui renvoyer un fichier ou doit appeler d'autres logiciels.
Serveur
Cela peut signifier une machine (ou plusieurs), ou un logiciel dont le but est de gérer votre requête, puis d'appeler d'autres logiciels que les développeurs ont choisies, avant d'envoyer une réponse.
Serveur Web
  On renvoie directement des fichiers.
Le serveur Web a trouvé un fichier à renvoyer directement.
Fichiers
S'il n'y a rien de trop malin d'impliqué, et que vous avez demandé un fichier "statique" comme une image (elle n'est pas censée changer si souvent), le serveur peut le renvoyer directement, et éviter d'appeler du code "plus intelligent".
6. On trouve ce qui sera responsable de répondre à la requête par des règles de routage (du serveur Web, serveur applicatif, ou les deux).
Routage
Il y a plein de choses que l'on peut faire, et donc plein de bouts de code possibles.
Le routage est responsable de trouver et d'appeler le bon.
∅
Chaque framework a sa façon de faire le routage, voici celle de Ruby on Rails.
Application
14. Renvoie le contenu : HTML (vue), donnée brute (XML/JSON), statut (OK ou code d'erreur), ou redirection.
7. C'est là qu'on intervient sur le code !
Serveur d'application
Le serveur d'application fait tourner le code. Il a besoin de faire des choses un peu différentes du serveur Web, c'est pour cela qu'on aime bien les séparer, notamment au cas où on n'aurait pas besoin de la pleine puissance du Serveur d'Application et que le Serveur Web suffit pour faire le travail.
Serveur d'applications
13. on "render" la vue à partir des données qui sont remontées.
Vues
Les vues sont principalement des morceaux d'HTML, avec des emplacements pour les données que le Contrôleur a été chercher.
MVC - Vue
12. Le contrôleur peut aussi appliquer des règles applicatives sur les données remontées par le modèle.
8. Le serveur applicatif appelle une action pour gérer la requête.
Contrôleur
Si vous utilisez un framework MVC, le Contrôleur gère la requête. Son travail est de faire les règles de l'application.
Il peut par exemple faire des vérifications de sécurité, de droits d'accès, et demander au Modèle les informations adéquates, puis faire tourner la Vue et vous renvoyer une réponse : contenu, fichiers, ou peut-être une redirection, c'est à dire sa manière de dire "ce n'est pas de mon ressort, demandez plutôt là-bas".
MVC - Contrôleur
11. Le modèle peut aussi appliquer des règles métier aux données qu'il récupère.
9. On demande au modèle d'aller chercher ou de croiser des données.
Modèle
Si vous utilisez un framework MVC, le Contrôleur demande des données au Modèle. Le modèle connaît des règles métier, et se connecte à la base de données.
Comment savoir si du code devrait être dans le Modèle ou le Contrôleur ? Si
  1. vous faisiez quelque chose qui n'est pas sur le Web, et que cette règle serait identique
  2. vous faisiez plusieurs applications, et que cette règle serait identique entre elles
  3. le contrôleur est trop long, vous devriez probablement déléguer quelques règles au modèle

MVC - Modèle
Bases de données
10. la base de données recherche ou écrit des informations pour les stocker dans la durée.
Base de données
La base de données est là où vos données sont conservées. Elles utilisent des logiciels très spécialisés, optimisés pour des recherches rapides ou de la haute disponibilité.
Chacune propose un certain nombre de propriétés, comme conserver les données en état même en cas de coupure de courant.
Base de données