La première partie de l’article expliquait le fonctionnement d’une page web côté client.
Voyons voir maintenant ce qu’il se passe côté serveur.

Partie II

Côté serveur : formulaires et bases de données

1. Formulaires

Jusqu’à présent, nous avons uniquement parlé de la récupération de données du serveur. Qu’en est-il de l’envoi de données ? Les formulaires sont l’autre côté du HTML : ils nous permettent d’envoyer des informations au serveur. Nous pouvons utiliser les formulaires pour mettre à jour des informations existantes ou pour ajouter de nouvelles informations.
Les méthodes les plus couramment utilisées dans les formulaires HTML sont GET et POST.

Jetez un oeil au code ci-dessus :
Nous avons deux champs de saisie (input) dans lesquels l’utilisateur peut entrer des données et un bouton de soumission (submit).
Une fois que l’utilisateur a cliqué sur ce bouton, le navigateur envoie les valeurs des données saisies dans les deux champs à un script PHP appelé createproduct.php.
Dans notre exemple, c’est du PHP, mais ce pourrait être du JSP, du Python ou n’importe quel autre langage de script côté serveur. Le script côté serveur peut lire les valeurs envoyées par le navigateur via la méthode POST, puis les traiter ou les stocker dans une fichier ou une base de données. En résumé, c’est la manière dont sont envoyées les données au serveur avant d’être stockées.

Qu’est-ce que le PHP ?

PHP pour Hypertext Preprocessor, est un langage de script côté serveur qui permet de créer des sites et applications web dynamiques. Autrement dit : c’est un langage qui permet d’accéder et de lire une base de données puis de retranscrire ses informations au sein d’une page HTML.
Note : Imaginons que nous voulons ajouter des validations avant d’envoyer les données — par exemple, le nom du produit doit contenir 5 caractères minimum, ou le champ “SKU” ne doit pas être vide. Nous pouvons utiliser du JavaScript pour ces validations. Nous allons alors devoir réagir à l’événement clic du bouton de soumission, et vérifier si les éléments web ont bien les données que nous souhaitons. S’il manque quoi que ce soit, nous pouvons afficher un message d’erreur et stopper l’envoi des données au serveur.

2. Bases de données

Dès que la quantité d’informations commence à grandir, les récupérer depuis des fichiers peut devenir vraiment compliqué en plus d’être très lent. Par exemple, prenons le fichier de liste de prix, supposons que l’entreprise a des milliers de produits et que nous voulons connaître les informations du dernier produit de la liste — ce qui signifie que nous avons besoin de lire tous les produits jusqu’à ce que nous trouvions celui que nous recherchons. Ce n’est pas une façon optimale de récupérer une information. C’est pour résoudre ce problème que les bases de données ont été créées.
Dans une base de données (DB), nous stockons les données dans des tables (un ensemble structuré de données). Ainsi, nous pouvons facilement effectuer une recherche, trier les données ou réaliser tout autres opérations.

3. Langages de script côté serveur & frameworks

Nous avons besoin des langages de script côté serveur pour :

stocker et lire des informations depuis une base de données ou un fichier ;
obtenir (GET) les informations d’un serveur en effectuant certaines opérations ;
lire les informations envoyées par le client (POST) et les stocker ou les diffuser en effectuant certains traitements.

Les langages de programmation typiques tels que le C et le Java peuvent lire et écrire dans les bases de données, mais ils ne peuvent pas être directement exécutés sur le navigateur web (client). Cela a donné naissance à des langages de script côté serveur.
Les langages de script côté serveur peuvent effectuer tous les traitements de données habituels, communiquer avec les bases de données, et être exécutés sur un serveur web. Les langages de script côté serveur les plus courants sont PHP, Perl, JSP, Ruby on Rails, etc.
Les développeurs ont commencé à utiliser ces langages et ils se sont vite rendu compte qu’ils écrivaient le même code standard pour tous les projets, ce qui a conduit au développement de frameworks qui facilitent et accélèrent le développement d’applications web.
Quelques frameworks connus :

PHP : Zend, YII, Symfony, CakePHP, Laravel ;
CMS PHP (aussi utilisés comme frameworks) : Drupal, Joomla, SugarCRM, WordPress ;
Java : J2EE, Hibernate, Struts, Spring ;
JavaScript : Node.js.

4. Architecture MVC & sessions

L’architecture MVC nous aide à diviser le code en plusieurs fichiers et nous permet de séparer la logique métier de la présentation, afin de faciliter leur modification ultérieure.
En prenant l’exemple d’une plateforme de blog, nous reviendrons sur tous les sujets précédemment expliqués pour voir comment nous pouvons coder en utilisant l’architecture MVC.
Une plateforme de blog gère du contenu dynamique et pourrait contenir plusieurs modules tels que :

Utilisateurs (users) ;
Articles (blog posts) ;
Mots clés / étiquettes (tags) ;
Catégories (categories).

Avant de parler d’autres fonctionnalités, imaginons la conception de base de données pour la table des Articles (tbl_blog_post). Les champs importants seraient :

Comme vous le voyez, nous stockons les informations de l’utilisateur en double : le prénom (First Name) et le nom de famille (Last Name) répètent le contenu du champ Created By. Si nous avons 10 000 articles de blog, nous allons stocker ces informations utilisateur dupliquées dans chacun des 10 000 articles. Et il pourrait y avoir encore d’autres informations concernant l’utilisateur à sauvegarder, comme par exemple son rôle, sa date de dernière connexion, etc.
L’alternative, comme vous avez peut-être déjà deviné, est de stocker ces informations utilisateur dans une autre table Utilisateur (tbl_user) et de la relier à celle des articles (tbl_blog_post) par un identifiant comme ci-dessous :

Cette séparation des données en plusieurs tables est l’un des nombreux principes de normalisation des données.
Le prochaine partie importante est de permettre à l’utilisateur d’insérer des données dans ces tables via un formulaire HTML. Rappelez-vous que nous détaillons ces étapes pour comprendre les concepts — ce n’est en aucun cas un tutoriel complet de programmation.

Création d’un nouvel article de blog par un utilisateur authentifié

Pour cela, nous avons besoin d’un formulaire HTML avec deux champs de saisie (Titre, Contenu) à l’aide desquels l’utilisateur peut créer un article.
Une fois que l’utilisateur entre les informations et clique sur le bouton d’envoi, “Créer l’article”, les valeurs du formulaire sont envoyées au serveur web via la méthode POST. Les valeurs envoyées en POST peuvent être lues par n’importe quel langage de script côté serveur. Le script du serveur (PHP, Ruby on Rails, Python, etc.) lit la valeur du formulaire et la transmet à la base de données.
Le script peut aussi effectuer le traitement de l’information, qui peut être de récupérer la date et l’heure du serveur ou encore de faire certains calculs basés sur des valeurs extraites d’une autre table de la base ou d’un autre service web.
Autre point à noter : le script peut également effectuer des validations, aussi appelées validations côté serveur, afin de s’assurer que les données sont valides. C’est seulement si les données sont valides qu’elles sont enregistrées dans la table tbl_blog_post. Sinon un message d’erreur est envoyé au client pour qu’il entre les informations manquantes.
Visuellement, le formulaire pour récupérer les données de notre table tbl_blog_post pourrait ressembler à l’interface de création d’article de WordPress :

On y retrouve bien un champ pour saisir le titre (Title), puis une zone de saisie pour le contenu (Content).
La date de création (Created On), quant à elle, est récupérée dynamiquement par le langage de script (ici, PHP) et correspondra à l’instant exact de création de l’article (année, mois, jour, heure, minute et même seconde).
Autre donnée qu’il n’est pas nécessaire de saisir : l’identifiant de l’article (ID). Il est généré automatiquement par la base de données qui veille à ce qu’il soit unique au sein d’une même table.
Dans notre table tbl_blog_post, en plus du titre et du contenu, nous avons aussi un champ appelé created_by.
Comment obtenons-nous la valeur pour remplir ce champ ?

Utilisateur connecté / authentifié

Généralement, la plupart des applications web ont une fonctionnalité de connexion. À chaque fois qu’un utilisateur s’authentifie correctement, les informations de cet utilisateur sont stockées dans des sessions afin que ces informations puissent être réutilisées plus tard.

Qu’est-ce qu’une session ?

HTTP est un protocole sans état, ce qui veut dire qu’aucune requête GET ou POST émise par le client au serveur web n’est trackée. Si le client (le navigateur) fait deux requêtes, le serveur web ne sait pas si elles proviennent du même utilisateur. Cela signifie aussi que, par exemple, si vous êtes connecté sur un site e-commerce et que vous ajoutez des produits à votre panier, le serveur ne sait pas qu’ils sont pour le même utilisateur.
Afin de pallier à cet absence d’état, les clients ont besoin d’envoyer des informations supplémentaires dans chacune de leurs requêtes pour pour conserver les informations de session pendant la durée de plusieurs requêtes. Ces informations supplémentaires sont stockées côté client dans les cookies, et côté serveur dans les sessions.
Une session est un tableau de variables, dans lesquelles les informations sont enregistrées afin d’être utilisées sur plusieurs pages. Les sessions sont identifiées par un ID unique dont le nom dépend des langages — en PHP, il est appelée “PHP Session ID”. Ce même identifiant de session doit être stocké dans un cookie sur le navigateur afin d’être associé à l’utilisateur.

Afficher un seul article

La prochaine étape est d’afficher les articles de blog individuellement. Nous devons lire les données de la base en fonction de l’identifiant de publication (ID) de l’article demandé, puis afficher les valeurs des champs Titre (Title) et Contenu (Content).
Voici le pseudo-code pour afficher un seul article :

Lire les données de la base associées à l’ID de l’article.
Insérer ces données dans une page HTML contenant le CSS et le JS.

Tout le code ci-dessus peut être écrit dans un seul fichier. C’est d’ailleurs de cette façon que cela a été fait au début, mais la communauté de développement a réalisé que ce n’était pas optimal. En effet, pour chaque nouvelle fonctionnalité à ajouter, le code entier devait être modifié, et ce n’était pas facile de travailler dans un environnement multi-développeurs.
Cela a amené les développeurs Web à adopter l’architecture MVC, qui dissocie essentiellement le code en trois composants :

Le Modèle : C’est la logique métier, indépendant de l’interface utilisateur. Dans notre exemple, il s’agit du code qui récupère les articles dans la base de données.
La Vue : Une vue une représentation visuelle des données. Dans notre exemple, c’est le code HTML qui affiche les articles. Ainsi les données proviennent du Modèle, et le HTML est la Vue.
Le Contrôleur : Il est appelé au clic sur le lien “Voir l’article”. Le Contrôleur récupère les données de la base à l’aide du Modèle et les affiche dans la Vue.

Examinons une URL typique d’une application utilisant l’architecture MVC.
http://www.abc.com/blogpost/id/1
Ici, blogpost est le nom du contrôleur et la vue est une action (méthode) de ce contrôleur. id est l’identifiant de l’article. Si nous entrons cette URL dans un navigateur, la requête va aller à l’action “View” du contrôleur “BlogPost”, et y appeler le modèle pour obtenir le contenu de l’article d’ID “1”, sous la forme d’un objet. Cet objet est ensuite passé à la “Vue” pour être affiché.
Plus concrètement : l’URL suivante https://www.ux-republic.com/blog/page/2 affiche la deuxième page de la liste des tous les articles du blog UX-Republic.
En décomposant l’URL, nous avons :

blog, le contrôleur
page, l’identifiant qui désigne le n° de la page
2, le n° de la page

À chaque clic sur la pagination, c’est la même méthode du contrôleur blog qui est exécutée et qui se charge de récupérer le contenu correspondant à la page sélectionnée.

Ajax & Single Page Applications (SPA)

Si vous êtes né au dernier millénaire, vous devez vous rappeler des fournisseurs de messageries web Hotmail et Yahoo!, très populaires dans les années 1990 et 2000. Quand vous cliquiez sur la boîte de réception ou sur un e-mail, la page entière était actualisée. Vers 2004, Gmail est arrivé avec une fonctionnalité importante : Ajax. Avec Ajax, toute la page n’est pas actualisée — seules les parties qui en ont besoin le sont. Du coup, si vous recevez un nouvel email, vous le voyez simplement apparaître en haut de la page, sans avoir à la recharger. Cela a permis de donner aux utilisateurs une meilleure expérience de navigation, et Ajax est devenu un moyen très populaire de créer des applications.

Qu’est-ce que Ajax ?

Le terme Ajax représente un large groupe de technologies web pouvant être implémentées dans une application communiquant avec un serveur en arrière-plan, sans interférer avec l’état actuel de la page.
Avec Ajax, vous envoyez une requête en GET au serveur, et le serveur envoie sa réponse sans bloquer la page web, ce qui signifie que l’utilisateur peut continuer à naviguer sans aucune interruption. La réponse du serveur est insérée ou ajoutée à la page web en cours.
Sur les sites n’utilisant pas Ajax, chaque action de l’utilisateur nécessite un complet rechargement de la page depuis le serveur. Ce processus est inefficace et crée une mauvaise expérience utilisateur car tout le contenu de la page disparaît avant de réapparaître.
Ajax est une des techniques utilisée pour construire des applications à page unique (Single Page Applications ou SPAs). Comme le nom l’indique, toute l’application tient sur une seule page et tout son contenu est chargé dynamiquement. Des frameworks JavaScript comme Angular, React, et Backbone.js peuvent être utilisée pour faire des SPAs.

Serveurs & navigateurs web

Les navigateurs sont les interprètes du web. Ils demandent des données aux serveurs web, qui traitent la requête et envoient une réponse au navigateur en HTML (avec le CSS, le JS, les images, etc.), et cette réponse est ensuite affichée.
Une requête au serveur web peut être faite en utilisant l’une de ces trois méthodes importantes :

GET : récupère la ressource demandée en tant que réponse ;
HEAD : idem que GET, mais la ressource est récupéré en entête de la réponse ;
POST : envoi les données au serveur.

Par exemple, quand vous tapez “google.com” dans le navigateur, ce dernier envoie en arrière-plan cette commande au serveur google.com :
GET: http://google.com
Le serveur web Google va alors regarder son fichier principal (index) et renvoyer sa réponse au client. Il envoie généralement du contenu HTML et des fichiers CSS, ainsi que tout autre fichier multimédia.

# Traduction de l’article Understand Web Development in Less than 1 Hour, par Shaik Ismail

Comprendre le développement web en moins d'une heure [part 2]