La particularité du Web est qu'elle réside sur une architecture client-serveur.

Ceci requiert une connectivité permanente mais donne également énormément de possibilités.

Par exemple, ChatGPT requiert une puissance de calcul gigantesque (258 000 cores de processeurs pour GPT-3) mais est accessible via n'importe quel ordinateur ou smartphone.

Analogie douteuse: cuisiniers du McDonalds

Clients et serveurs communiquent par message structuré (première ligne, l'en-tête, corps).

Voici les principales méthodes HTTP

GET

Demande de récupération de données (par défaut)

POST

Envoi de données via un formulaire

DELETE

Demande de suppression

PATCH

Demande de modification partielles

PUT

Demande de modification

Pour plus de détails, vous pouvez visiter la documentation

• Réponses informatives (100-199)
• Réponses de succès (200-299)
• Messages de redirection (300-399)
• Erreurs Client (400-499)
• Erreurs serveur (500-599)

Pour plus d'information, consultez la documentation

Le protocole HTTP est comme Dory, il oublie les requêtes des clients dès qu'il les a traitées.

Le client doit rappeler à chaque requête qui il est via ce qu'on appelle des cookies (dans quelques slides)

L'idée des cookie est que le client rappelle au serveur qui il est à chaque requête parce que le serveur a oublié (une promenade en mer, une promenade en mer).

Le tracking est le business model du Web. Les géants du Web ont pratiquement votre historique complet.

La sécurité du Web fonctionne sur la cryptographie asymétrique.

• Deux clés inverses l'une de l'autre: un message crypté avec l'un peut être déchiffré avec l'autre.
• Objectifs:
  • Confidentialité
  • Authentification de l'expéditeur
• Le nom public/privé vient de si cette clé est partagée ou non.

Les requêtes HTTP sont lisibles par toute personne qui se trouve sur le réseau entre le client et le serveur. En particulier, une personne peut lire vos mots de passe et données bancaires.

Il existe plusieurs manières de créer un site ou une application web. La décision qui différencie ces architectures est la répartition du travail entre serveur et client.

1. Sites statiques
2. MPA
3. SPA
4. SSR

Dans un site statique, le serveur ne traite généralement que les requêtes GET. Les chemins de l'URL font référence à un chemin sur le disque dur du serveur relativement à un dossier racine.

En particulier, on n'a pas accès à des base de données, on ne peut pas traiter de formulaires, etc.

Pour fournir une expérience personnalisée à l'utilisateur, nous voulons que la page soit potentiellement différente pour chaque utilisateur. On parle alors d'application.

Nous distinguerons deux types d'application:

• MPA
• SPA

La distinction SPA/MPA se fait sur le nombre de pages que comporte l'application.

• Si l'application a une page, c'est une SPA.
• Si l'application a plusieurs page, c'est une MPA.

• Les SPA sont plus rapides (après le premier chargement) puisqu'elles ne contactent le serveur spécifiquement que pour des informations manquantes.
• Les SPA surchargent moins le serveur puisque plus de travail est effectué côté client.
• Les SPA offrent plus de possibilités d'UX (scroll infini, offline mode, position du curseur, etc.)

Cette technique s'appelle le client-side routing: on emploie le JavaScript pour faire semblant de changer de page.

Chaque fois qu'on résoud un problème en frontend, on en crée un nouveau. Le SSR crée le problème de l'hydration, une période durant laquelle la page est affichée mais pas interactive.

Ce problème n'est pas encore résolu de manière satisfaisante, bien qu'il existe des projets prometteurs tels que Qwik ou Astro