Introduction aux services web — Alexandre Niveau

Service web

Programme qui tourne sur un serveur web
Fournit un service à des utilisateurs « machines »
Comme une application web, mais utilisable par des programmes

Utilisation d'un service web

Les services web sont utilisés par les sites web pour améliorer l'expérience utilisateur, ou pour faire des widgets
Quelques exemples :
- page d'un magasin intégrant un plan Google Maps
- page décorée automatiquement avec des photos issues de Flickr
- page personnelle intégrant les derniers tweets de l'auteur
- outil de recherche intégré à la page mais fourni par Google ou Yahoo

Service Oriented Architecture

Architecture orientée service : modèle d'application qui met en œuvre des services complètement indépendants mais interopérables
Les services sont des briques de base qui permettent de créer des services plus complexes (qui peuvent à leur tour être utilisés comme briques de base)
Dans cette définition, un web service est :
- un composant métier
- autosuffisant
- exécuté sur le web
- remplissant un contrat (format standard pour les requêtes et réponses, API et protocole connus)
Recommandation W3C sur l'architecture des web services

Standards pour les services web

Dans le cadre d'une architecture orientée services, nécessité de standards pour que les services soient interopérables
Standards du W3C :
- XML pour le format des données
- SOAP pour le format des requêtes
- WSDL pour la description de l'interface du service

SOAP

Simple Object Access Protocol
Protocole pour l'envoi des messages
Basé sur XML
Au-dessus de la couche du protocole de transmission (généralement HTTP ou SMTP)
Créé par Microsoft en 1998, puis proposé comme standard au W3C (recommandation W3C)

Principe de SOAP

Exemples de messages SOAP (service de recherche Google, supprimé)

WSDL

Après la standardisation de SOAP : volonté de développer une architecture orientée services
Il fallait pouvoir définir les API des services de façon standard
Septembre 2000 : WSDL, Web Services Description Language, développé notamment par IBM et Microsoft, puis standardisé par le W3C
Quoi : modèle du service
Comment : lie le modèle à son implémentation
Où : point d'accès au service
Exemple de Google (service supprimé)

SOAP et PHP

Classe SoapClient
Peut être instanciée à partir d'un fichier WSDL
Méthode = fonction de service interrogé
resultElements est un tableau composé des résultats (les données XML ont été parsées)

Un client SOAP


<?php
try{
    $options = array(
        'proxy_host' => "proxy.info.unicaen.fr", 'proxy_port'=> 3128,
        'trace' => true);
    $client = new SoapClient("GoogleSearch.wsdl", $options);
}
catch(Exception $e) { echo $e->getMessage();}

$cle = "FjHwko9QFHL/EYmp3hblb/3YsAMQR/Ys";
$res = $client->doGoogleSearch($cle, "ajax", 0, 10, false, "", false, "", "", "");
$tab  = $res->resultElements;

for ($i=0; $i < sizeof($tab); $i++) {
  echo $tab[$i]->title ." à l'url ".$tab[$i]->URL ."<br>";
}
?>

Avantages et inconvénients de SOAP

SOAP est un protocole standard, indépendant du protocole de transport utilisé
Développé pour être extensible autant que possible…
… ce qui le rend naturellement lourd à manipuler
Couplage fort entre client et serveur : modification de l'API implique une modification chez le client
Conséquence : perte de vitesse depuis des années au profit de REST

REST

REST : Representational State Transfer
Style d'architecture, pas un protocole ou un format
Ensemble de contraintes, proposées par Roy Fielding dans sa thèse en 2000
Un système est conforme (« RESTful ») s'il respecte les contraintes
Objectifs : simplicité des interfaces, portabilité, scalabilité, fiabilité à long terme

Contraintes de REST

Modèle client-serveur
Sans état : les requêtes sont indépendantes
Possibilité d'utiliser un cache pour les réponses
Interface uniforme séparant le client et le serveur

Interface uniforme

C'est un des points fondamentaux, qui permet le découplage strict entre client et serveur
En particulier, l'architecture REST manipule des ressources, qui doivent
- avoir un identifiant unique (ex. URI)
- être manipulables par les clients via des représentations bien définies (ex. HTML, JSON…)
Les messages :
- doivent être autodescriptifs, i.e. contenir une explication de comment les utiliser
- doivent contenir des hyperliens indiquant ce qu'il est possible de faire ensuite

REST en pratique

Exemple d'architecture REST : le web, en tant que système de diffusion de documents (implémenté par la combinaison HTTP, HTML, URI)
mais les services web ne sont pas forcément conformes
Le concept de REST a été très à la mode dans les années 2000, comme solution à la lourdeur de SOAP/WSDL
Souvent mal interprété : nombreux services web basés sur HTTP autoproclamés RESTful pour des raisons marketing
Au sens large, on parle de REST quand la requête est faite via HTTP GET/POST (exemple)

Conception d'une API REST (1)

Dans un sens plus strict, l'API d'un service REST a les caractéristiques suivantes (dans l'ordre des priorités)

utilise des URI bien choisies qui représentent des ressources :
```
/users/bob/messages/354
```
en exploitant l'aspect hiérarchique, chaque composant du chemin ayant une sémantique et une hiérarchie bien pensée, rép = collection et n'utilise les paramètres que pour filtrer ou rechercher:
```
/users/bob/messages/?date=2015-02-23&sort=title
/users/?q=bob
```
utilise les verbes HTTP pour les actions :
- GET /users/bob renvoie Bob
- GET /users/ renvoie la liste des utilisateurs
- POST /users/ ajoute un nouvel utilisateur
- PUT /users/bob modifie Bob
- DELETE /users/bob supprime Bob

Conception d'une API REST (2)

utilise les codes de statut HTTP pour indiquer le résultat de la requête :
- les habituels 200 OK, 403 Forbidden, 404 Not Found, 500 Internal Server Error, etc.
- mais aussi 201 Created, 405 Method Not Allowed, 409 Conflict, etc.

plus rarement, utilise des liens dans les réponses pour une API auto-descriptive et découvrable :

<message>
  <text>bla bla bla</text>
  <link rel = "self"
        uri = "/users/bob/messages/354" />
  <link rel = "prev"
        uri = "353" />
  <link rel = "next"
        uri = "355" />
  <link rel = "/linkrels/message/new"
        uri = "../"
        method = "POST" />
</message>

Sémantique du lien donné par l'attribut rel, pour laquelle il existe des valeurs standard (on peut spécifier une valeur non-standard avec une URI).

Interroger un service REST

Un service REST s'interroge par une URI avec les paramètres nécessaires
Faisable directement dans un navigateur par un humain (pour les requêtes GET)
En Javascript, utilisation de XMLHttpRequest
En PHP, utiliser CURL
Résultats en XML ou JSON généralement
En PHP, utiliser SimpleXML et json_decode

Exemple en REST

Service web de recherche de localités : geonames-search
Exemple de requête : http://api.geonames.org/search?q=caen&maxRows=10&username=demo
Et en JSON : http://api.geonames.org/searchJSON?q=london&maxRows=10&username=demo

Démo : client PHP très simple interrogeant Geonames

Autres exemples : Google Books API, Twitter, Flickr, API Wikipédia…

Exemple de classe PHP interrogeant Flickr (pas exécutable sans clef)