Chapitre 4 Les services web REST sémantique
68
? ressources identifiées par des URIs
? ensemble de méthodes réduit (GET, PUT, POST,
DELETE, ...) ? ressource manipulées par leur représentation
Cette interface uniforme nous permet-elle enfin de pouvoir
parler d'interopérabilité ? non, le style d'architecture REST ne
nous permet pas de nous assurer que notre application sera
interopérable. Pourquoi ? Tout simplement parce qu'il paraît
aujourd'hui très difficile de développer des systèmes
totalement interopérables. Chaque application se place dans un domaine
métier précis et possède son vocabulaire. Mais le style
d'architecture REST permet de simplifier l'intégration de nouvelles
applications à notre système existant.
D'une part grâce au modèle d'adressage uniforme
des ressources (URI). Tous les composants du système utilisent le
même outil pour nommer les choses. Il est plus facile de les manipuler.
Le paradigme d'appel de méthode à distance utilise le nom des
méthodes métiers pour identifier le service sur le web.
L'adressage est donc totalement spécifique au service.
Ensuite, l'utilisation d'un nombre réduit de
méthodes permet aux clients de savoir, avant même de contacter le
service, quelles méthodes sont disponibles. De plus, la
sémantique de ces méthodes étant définie
clairement. Si le client veut récupérer une ressource, il y a de
forte chance que la méthode GET fonctionne. Un client SOAP ne pourra
jamais deviner le nom des méthodes avant d'avoir consulter le contrat
WSDL.
Enfin, le fait de ne pas spécifier le format des
messages échangés permet de rendre indépendant
l'évolution du langage (format des données) et du support de
communication (protocole). Cette indépendance permet d'interconnecter
plus facilement des composants qui n'ont à priori rien à voir
ensemble. L'exemple le plus connu actuellement est celui de RSS. Un client peut
tirer partie de l'information fournie par un flux RSS sans se soucier de la
façon dont il a été généré.
En standardisant le protocole de communication, le style
d'architecture REST permet de se concentrer sur la véritable source de
couplage fort : le format de données échangées. Dans son
article « SOAP, REST and Interoperability » Paul Prescod cite 4
technologies pouvant aider à la résolution de cette
problématique :
? transformations XSLT
? l'héritage de schémas XML
? XML générés par des requêtes XML
? RDF, DAML+OIL et les technologies du web sémantique
5.2 Les aspects non fonctionnels
Nous n'avons pas encore parlé des aspects non
fonctionnels des web services : sécurité, qualité de
services, monitoring, ... Le respect d'une architecture de type REST facilite
la mise en place de ces fonctionnalités pour différentes raisons
:
| 
