Les fournisseurs et consommateurs M2M
Les expressions fournisseur et consommateur de web service reviennent fréquemment. il est nécessaire de bien assimiler ces expressions pour avoir une vision cohérente des échanges M2M.
La notion de service web
Quand vous consultez une page web, vous consultez généralement les informations reçues au travers d'un écran informatique (PC, tablette, téléphone mobile...).
Pour avoir ces informations, vous avez effectué une requête, soit en cliquant sur un lien, soit en tapant une adresse URL.
C'est typiquement une relation homme-machine. Pour une page web, les informations reçues ont été envoyées par l'intermédiaire d'un protocole http qui exploite le port 80 ou 8080 pour une connexion non sécurisée, ou https pour une connexion sécurisée.
Un WS va exploiter ce même protocole http ou https, comme un être humain, mais effectuera des échanges normalisés afin de permettre un traitement automatisé beaucoup plus efficace dans cette relation M2M.
Un WS est un échange d'information normalisé M2M utilisant les mêmes ports et protocoles qu'un échange homme-machine.
Web service: Ensemble de fonctionnalités accessibles sur Internet et permettant la communication ainsi que l'échange automatique et en temps réel de données entre applications et systèmes hétérogènes.
Le consommateur de WS
Lors de l'accès aux pages web d'un serveur, dans un échange homme-machine, l'être humain est toujours consommateur d'information.
Il en est de même dans une relation M2M
Le consommateur de WS sera notre serveur Internet. Ce n'est plus un utilisateur humain qui va chercher des informations, mais un script au sein d'un serveur qui interroge une autre machine.
Le système est consommateur de WS quand il interroge une autre machine:
- en architecture REST (Representational State Transfer)
- en architecture SOAP (Simple Object Access Protocol)
Dans les deux architectures, on structure les interrogations vers le serveur. L'architecture REST est beaucoup plus simple que SOAP. En architecture REST, l'interrogation d'un serveur est de cette forme:
http://wwwle-site-serveur/script.php?method=fiche¶m=1En fait, ça ressemble à quelque chose de connu: les URLs que nous utilisons régulièrement en naviguant sur le web.
Voici un extrait de résultat de WS REST:
<?xml version="1.0" encoding="UTF-8"?> <ISBNdb server_time="2014-03-19T12:45:56Z"> <BookList total_results="1" page_size="10" page_number="1" shown_results="1"> <BookData book_id="savoir_tout_faire_bricolage" isbn="2706600586"> <Title>Savoir tout faire Bricolage</Title> <TitleLong>Savoir tout faire Bricolage (French Edition)</TitleLong> <AuthorsText>Michel Beauvais, </AuthorsText> <PublisherText publisher_id="flammarion">FLAMMARION</PublisherText> </BookData> </BookList> </ISBNdb>
C'est le résultat de l'interrogation d'un serveur de bibliothèque publique.
Le serveur que nous avons interrogé est fournisseur de WS.
Le fournisseur de WS
Le serveur qui diffuse des données suite à des requêtes REST ou SOAP est le fournisseur de WS.
Le fournisseur de WS traite les demandes comme un serveur web classique, mais au lieu de renvoyer une page web, il renvoie le résultat généralement sous forme de flux XML:
- architecture SOAP: renvoie toujours un flux au format XML;
- architecture REST: renvoie généralement un flux au format XML, mais peut - sur demande - transmettre dans d'autres formats: JSON, CSV, etc...
L'architecture REST est plus souple, car un même WS peut profiter à un service consommateur de flux XML, ou une requête Ajax qui préférera un flux de données au format JSON.
Exemple de résultat de requête WS REST au format JSON:
{ "data" : [ { "author_data" : [ { "id" : "michel_beauvais", "name" : "Michel Beauvais" } ], "subject_ids" : [ "education_reference_foreign_language_study_reference" ], "book_id" : "savoir_tout_faire_bricolage", "dewey_decimal" : "", "lcc_number" : "", "dewey_normal" : "0", "publisher_id" : "flammarion", "awards_text" : "", "publisher_text" : "FLAMMARION", "summary" : "", "title" : "Savoir tout faire Bricolage", "isbn13" : "9782706600586", "physical_description_text" : "7.7\"x10.7\"x1.2\"; 3.4 lb", "urls_text" : "", "language" : "", "publisher_name" : "FLAMMARION", "isbn10" : "2706600586", "marc_enc_level" : "~", "title_latin" : "Savoir tout faire Bricolage", "edition_info" : "Hardcover", "notes" : "", "title_long" : "Savoir tout faire Bricolage (French Edition)" } ], "index_searched" : "isbn" }
Ce flux de données est exploitable au format JSON directement par un script Javascript.
Intérêt des services web
Un WS est intéressant pour le partage d'informations entre systèmes hétérogènes.
Le flux de données résultat émis par un WS ne contient aucune mise en forme, contrairement à une page WEB.
L'accès au WS se fait de manière similaire à l'accès à n'importe quelle page web via le protocole http ou https. Donc, un serveur proxy dans un réseau Intranet ne bloquera pas un WS s'il ne bloque pas l'accès à la racine du serveur qui héberge le WS.
De nombreux serveurs collectent et traitent des informations, parfois en volume très conséquent. la mise à disposition de ces informations par WS évite en particulier la réplication de la base de données d'un serveur sur autant de systèmes utilisateurs.
Les WS ont des applications dans tous les domaines. Seule condition: que les informations soient disponibles par WS.
Quelques exemples:
De nombreux serveurs publics fournissent des WS:
- l'API de Google Maps;
- l'API de Facebook
- l'API de eBAY
- l'API de TWITTER
- l'API de AMAZON, etc...
La plupart de ces serveurs nécessitent une clé utilisateur et certaines fonctions sont limitées en quota.
Pour EBAY par exemple, il est possible, en seulement quelques appels de WS de trouver la liste des ventes en cours dans une catégorie donnée.
Voyons maintenant comment monter notre premier WS en tant que fournisseur sur notre serveur.