Différences

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

--- bloc2:prog:web:webservices [2023/11/24 13:36] – [Présentation] admin
+++ bloc2: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:
   * **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, 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 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 =====
@@ Ligne 15: / Ligne 17: @@
   * 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 ;
-{{  :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.
@@ 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**.
-{{ :bloc2:prog:web:bloc2-prog-web-servweb-schema.png?600 |}}
+{{ bloc2:prog:web:servweb-schema.png?600 |}}