Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
reseaux:internet:rest [2021/11/11 10:03] – [Le modèle client-serveur du Web] phil | reseaux:internet:rest [2022/08/06 09:00] (Version actuelle) – [2. Le nommage] phil | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
[[reseaux: | [[reseaux: | ||
- | ===== REST - Le nommage | + | ===== L' |
{{ : | {{ : | ||
[Mise à jour le 11/11/2021] | [Mise à jour le 11/11/2021] | ||
Ligne 25: | Ligne 25: | ||
* **interface uniforme** : elle fait référence aux principes selon lesquelles une ressource doit avoir une seule représentation telle que les **URI** (**U**niform **R**esource **I**dentifier), | * **interface uniforme** : elle fait référence aux principes selon lesquelles une ressource doit avoir une seule représentation telle que les **URI** (**U**niform **R**esource **I**dentifier), | ||
- | <note>Le respect de ces règles permet l’évolutivité du système en ajoutant continuellement des acteurs et de nouvelles données. L’objectif principal est de simplifier le comportement du serveur afin de servir le plus grand nombre de requêtes possible.</ | + | <callout type=" |
==== 2. Le nommage ==== | ==== 2. Le nommage ==== | ||
- | Chaque ressource du Web est identifiée par une valeur unique appelée URI (Uniform Resource Identifier). Si l’URI contient des caractères internationaux, (comme les lettres accentuées, ...) | + | <callout type=" |
- | Les URI permettent de désigner une ressource de manière non ambigüe, c' | + | Les URI permettent de désigner une ressource de manière non ambigüe, c' |
- | Par exemple, on a une image que l'on veut identifier, on peut l'appeler | + | <callout type=" |
- | " | + | Par **exemple**, |
+ | |||
+ | * " | ||
mais il y a peu de chance que ce nom soit unique, d' | mais il y a peu de chance que ce nom soit unique, d' | ||
- | 33667789078image | + | * 33667789078image |
qui sera unique si je ne nomme qu'une seule ressource " | qui sera unique si je ne nomme qu'une seule ressource " | ||
- | 33667239018image | + | * 33667239018image |
sans ambiguïté possible. Cependant, comme le numéro de téléphone est unique dans l' | sans ambiguïté possible. Cependant, comme le numéro de téléphone est unique dans l' | ||
Ligne 48: | Ligne 50: | ||
Pour éviter les conflits, il est intéressant de donner, au début l' | Pour éviter les conflits, il est intéressant de donner, au début l' | ||
- | tel: | + | * tel: |
et | et | ||
- | ss: | + | * ss: |
On aura donc deux identifiants uniques, même si le hasard a fait que ce numéro de téléphone et ce numéro de sécurité sociale coïncident. | On aura donc deux identifiants uniques, même si le hasard a fait que ce numéro de téléphone et ce numéro de sécurité sociale coïncident. | ||
Ligne 58: | Ligne 60: | ||
Les URI formalisent ce principe. Le [RFC 3986] explique comment ils peuvent être construits. | Les URI formalisent ce principe. Le [RFC 3986] explique comment ils peuvent être construits. | ||
+ | < | ||
+ | {{ : | ||
- | Un URI commence par un schéma indiquant l’autorité de nommage, suivi d’une valeur d’autorité puis d’un chemin dans l’espace d’autorité. Des caractères comme les ":" | + | Par **exemple** : |
+ | * < | ||
+ | * < | ||
+ | * < | ||
- | Par exemple : | + | Ainsi, si je mets une ressource sur mon site Web, celui-ci est identifié par un **nom de domaine**, par exemple |
- | mailto: | + | * < |
- | ssh://utilisateur@example.com | + | |
- | ftp://ftp.is.co.za/rfc/ | + | |
- | Ainsi, si je mets une ressource sur mon site Web, celui-ci est identifié par un nom de domaine, par exemple | + | |
- | http:// | + | Personne d’autre dans l’univers ne pourra identifier ses ressources avec cette chaîne de caractères puisque |
- | Personne d’autre dans l’univers ne pourra identifier ses ressources avec cette chaîne de caractères puisque example.com m’appartient. Je dispose donc d’un espace de nommage infini sous example.com qui me permet de désigner l’ensemble infini de ressources sans que personne d’autre ne puisse prendre les mêmes noms. Un URI est une construction administrative permettant d’attribuer un identifiant unique global à une ressource spécifique. | + | <callout type=" |
L’URI a pour but de facilement nommer une ressource, de pouvoir lier les ressources entre elles pour former cette toile d’araignée mondiale. Le schéma définit à la fois l' | L’URI a pour but de facilement nommer une ressource, de pouvoir lier les ressources entre elles pour former cette toile d’araignée mondiale. Le schéma définit à la fois l' | ||
- | Un sous-ensemble d’URI peut être directement utilisé pour localiser la ressource, c’est-à-dire trouver sur quel serveur se trouve la ressource et comment y accéder. Il s’agit d’une URL (Uniform Resource Locator) bien connue | + | < |
+ | |||
+ | Le schéma HTTP est pratique, car il peut se lire également comme un URL. Ce schéma donne : | ||
+ | |||
+ | * le **protocole** à utiliser pour accéder à la ressource (HTTP), | ||
+ | * l’**autorité** qui indique l’**adresse du serveur** (et son **port**), et enfin, | ||
+ | * le **chemin d’accès** de ce que l'on va demander au serveur et qui peut parfois correspondre à une arborescence de fichiers sur un serveur. | ||
+ | |||
+ | ==== 3. Serveur sans état ==== | ||
+ | <callout type=" | ||
+ | |||
+ | Cela impose que l’état soit situé du côté du client. Cet état est alimenté à partir des données structurées que le client reçoit du serveur. Ainsi, lorsqu’un client demande une page Web, celle-ci peut contenir d’autres URI pour la compléter, par exemple des images, des feuilles de style, des scripts, etc. | ||
+ | |||
+ | Le client doit donc comprendre les données que le serveur lui envoie et donc connaître le format de représentation de la ressource qu'il reçoit pour y retrouver les URI. Donc, **en plus de la ressource elle-même, le serveur ajoute des informations complémentaires, | ||
+ | |||
+ | HTTP est un protocole qui peut être utilisé pour mettre en œuvre un serveur Web en appliquant les principes de REST (qualifié en anglais de < | ||
+ | |||
+ | HTTP définit différentes **méthodes** permettant au client d’interagir avec les ressources sur le serveur : | ||
+ | |||
+ | * **GET** est utilisée pour récupérer la représentation d’une ressource (par exemple page Web, valeur de température d’un capteur, etc.). Par exemple, la figure ci-dessous donne le format d’en-tête HTTP GET pour récupérer ma page Web : | ||
+ | {{ : | ||
+ | |||
+ | * **HEAD** est utilisée pour récupérer uniquement les métadonnées présentes dans les en-têtes de réponse sans le corps de réponse ; | ||
+ | |||
+ | * **POST** est utilisée pour indiquer au serveur une nouvelle ressource | ||
+ | |||
+ | * **PUT** est utilisée pour stocker une ressource à l’endroit identifié par l’URI dans la requête. Si la ressource existe déjà, elle sera modifiée ; | ||
+ | |||
+ | * **PATCH** permet au client de ne modifier qu’une partie de la ressource ; | ||
- | Le schéma http est bien pratique car il peut se lire également comme un URL. Ce schéma donne : | + | * **DELETE** |
- | le protocole à utiliser pour accéder à la ressource (http), | ||
- | l’autorité qui indique l’adresse du serveur (et son port), | ||
- | et enfin, le chemin d’accès de ce que l'on va demander au serveur et qui peut parfois correspondre à une arborescence de fichiers sur un serveur. |