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 Prochaine révisionLes deux révisions suivantes | ||
reseaux:internet:rest [2021/11/11 10:44] – [2. Le nommage] phil | reseaux:internet:rest [2022/08/06 08:53] – [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 ==== | ||
- | < | + | < |
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' | ||
- | <note>Si vous voulez identifier une ressource, vous devez posséder une séquence unique : un numéro de téléphone, | + | <callout type=" |
Par **exemple**, | Par **exemple**, | ||
Ligne 71: | Ligne 71: | ||
Ainsi, si je mets une ressource sur mon site Web, celui-ci est identifié par un **nom de domaine**, par exemple example.com. Je suis propriétaire de ce nom. Je peux donc l’utiliser pour identifier de manière unique ma ressource. Si on reprend le principe de construction d’un URI, j’aurai : | Ainsi, si je mets une ressource sur mon site Web, celui-ci est identifié par un **nom de domaine**, par exemple example.com. Je suis propriétaire de ce nom. Je peux donc l’utiliser pour identifier de manière unique ma ressource. Si on reprend le principe de construction d’un URI, j’aurai : | ||
- | <nowiki> | + | * <html>< |
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 // | ||
Ligne 79: | Ligne 79: | ||
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' | ||
- | <note important> | + | <note important> |
- | Le schéma | + | Le schéma |
- | * le **protocole** à utiliser pour accéder à la ressource (http), | + | * le **protocole** à utiliser pour accéder à la ressource (HTTP), |
* l’**autorité** qui indique l’**adresse du serveur** (et son **port**), et enfin, | * 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. | * 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 ==== | ==== 3. Serveur sans état ==== | ||
- | Le principe REST permet de concevoir des serveurs évolutifs. **Un serveur doit être sans état**, ce qui signifie qu’**il ne conserve pas d’information après avoir répondu à une demande d’un client**. Cela permet de simplifier le traitement dans le serveur qui doit traiter les requêtes d'un grand nombre de clients. | + | < |
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. | 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. | ||
Ligne 94: | Ligne 94: | ||
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, | 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 les principes de REST (qualifié en anglais de RESTfull). HTTP définit différentes méthodes permettant au client d’interagir avec les ressources sur le serveur : | + | HTTP est un protocole qui peut être utilisé pour mettre en œuvre un serveur Web en appliquant |
+ | |||
+ | HTTP définit différentes | ||
* **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 : | * **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 ; | * **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 | * **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 ; | * **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 ; | * **PATCH** permet au client de ne modifier qu’une partie de la ressource ; | ||
+ | |||
* **DELETE** est utilisée pour supprimer la ressource définie. | * **DELETE** est utilisée pour supprimer la ressource définie. | ||