Wiki SIO Chaptal

Outils pour utilisateurs

Outils du site

Piste :
bloc2:prog:web:webservices

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
bloc2:prog:web:webservices [2023/04/07 15:13] – [Conventions REST] adminbloc2:prog:web:webservices [2023/11/28 14:20] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. admin
Ligne 6: Ligne 6:
 **<color #22b14c>Réponse</color>** : Il existe au moins deux manières de procéder: **<color #22b14c>Réponse</color>** : Il existe au moins deux manières de procéder:
   * **Utiliser les capacités du tableur à être programmé**. On peut, dans ce cas, stocker le programme dans le fichier tableur lui-même et s'appuyer sur la possibilité qu'il offre d'explorer une arborescence de fichiers pour lui faire créer une feuille de calcul à chaque exécution. Celle-ci sera remplie avec les données collectées par l'exploration. __Cette possibilité ne nous intéresse pas ici__ ;   * **Utiliser les capacités du tableur à être programmé**. On peut, dans ce cas, stocker le programme dans le fichier tableur lui-même et s'appuyer sur la possibilité qu'il offre d'explorer une arborescence de fichiers pour lui faire créer une feuille de calcul à chaque exécution. Celle-ci sera remplie avec les données collectées par l'exploration. __Cette possibilité ne nous intéresse pas ici__ ;
-  * **Utiliser l'[[https://fr.wikipedia.org/wiki/Interface_de_programmation|API]] du tableur** qui le rend accessible par programme. Pour cela, on peut utiliser l'environnement de programmation de son choix du moment qu'il est interfaçable avec cette API. Ce scenario est particulièrement intéressant puisqu'il permet de mesurer qu'__un logiciel destiné à une interaction avec un utilisateur peut, via une API, être aussi conçu pour fonctionner dans une interaction avec un autre programme__ ;+ 
 + 
 +  * **Utiliser l'[[https://fr.wikipedia.org/wiki/Interface_de_programmation|API]] du tableur** qui le rend accessible par programme. Pour cela, on peut utiliser l'environnement de programmation de son choix, pour peu qu'il soit interfaçable avec cette API. Ce scenario est particulièrement intéressant puisqu'il permet de mesurer qu'__un logiciel__ (ici le tableur) __destiné à une interaction avec un utilisateur peut, via une API, être aussi conçu pour fonctionner dans une interaction avec un autre programme__ ;
  
 ===== Définition ===== ===== Définition =====
Ligne 15: Ligne 17:
   * Besoin de mieux répartir les traitements entre client et serveur ;   * Besoin de mieux répartir les traitements entre client et serveur ;
   * Besoin de mieux prendre en compte la mobilité qui génère des temps hors-connexion ;   * Besoin de mieux prendre en compte la mobilité qui génère des temps hors-connexion ;
-{{  :bloc2:prog:web:bloc2-prog-web-servweb-schema.jpg?500  |Schéma de principe}}+{{  bloc2:prog:web:servweb-schema.jpg?500  |Schéma de principe}}
  
-Ajax permet déjà cela, mais l’idée ici est de pouvoir le faire sans le **XmlHttpRequest** qui n'est accessible que dans un navigateur. Il y a donc un travail particulier à faire côté serveur et côté protocole de communication. Les premières implémentations de services web étaient très ambitieuses et s'appuyaient sur des protocoles dédiés de type "usine à gaz", utilisant des échanges XML (ex. **SOAP** ou XML-RPC). +Ajax permet déjà cela, mais l’idée ici est de pouvoir le faire sans le **XmlHttpRequest** dont la vocation est de fonctionner dans un navigateur. Il y a donc un travail particulier à faire côté serveur et côté protocole de communication. Les premières implémentations de services web étaient très ambitieuses et s'appuyaient sur des protocoles dédiés de type "usine à gaz", utilisant des échanges XML (ex. **SOAP** ou XML-RPC). 
  
 L'expérience et le besoin de simplicité ont amené à la généralisation d'un standard nommé **REST** (REpresentational State Transfer) qui n'utilise rien d'autre que le potentiel existant du protocole **HTTP** couplé à des conventions de construction pour un usage homogène et cohérent.  L'expérience et le besoin de simplicité ont amené à la généralisation d'un standard nommé **REST** (REpresentational State Transfer) qui n'utilise rien d'autre que le potentiel existant du protocole **HTTP** couplé à des conventions de construction pour un usage homogène et cohérent. 
Ligne 29: Ligne 31:
   * <color blue>**Les verbes HTTP adressent l'opération**</color>. Au sens des données, il y a quatre opérations à assumer. Les verbes du protocole HTTP seront leur support :\\ \\    * <color blue>**Les verbes HTTP adressent l'opération**</color>. Au sens des données, il y a quatre opérations à assumer. Les verbes du protocole HTTP seront leur support :\\ \\ 
     * Insertion (Create) -> **POST**     * Insertion (Create) -> **POST**
-    * Consultation (Read) => **GET** +    * Consultation (Read) -> **GET** 
-    * Mise à jour (Update) => **PUT** +    * Mise à jour (Update) -> **PUT** 
-    * Mise à jour partielle (Update) => **PATCH** +    * Mise à jour partielle (Update) -> **PATCH** 
-    * Suppression (Delete) => **DELETE**+    * Suppression (Delete) -> **DELETE**
          
     <WRAP center round box 85%>     <WRAP center round box 85%>
Ligne 39: Ligne 41:
   * REST est conçu pour <color blue>**restituer des données structurées dans différents formats**</color> que l'on choisit à la demande lors de l'envoi d'une requête : il pourra s'agir de **CSV**, **HTML**, **XML** ou, plus communément aujourd'hui, **JSON**.   * REST est conçu pour <color blue>**restituer des données structurées dans différents formats**</color> que l'on choisit à la demande lors de l'envoi d'une requête : il pourra s'agir de **CSV**, **HTML**, **XML** ou, plus communément aujourd'hui, **JSON**.
  
-{{ :bloc2:prog:web:bloc2-prog-web-servweb-schema.png?600 |}}+{{ bloc2:prog:web:servweb-schema.png?600 |}}
bloc2/prog/web/webservices.1680873215.txt.gz · Dernière modification : 2023/04/07 15:13 de admin