Protocole SRU : Les protocoles de transport

Le protocole SRU (Search/Retrieval via URL), qui est basé sur l’usage d’URLs, utilise techniquement le protocole de communication client/serveur HTTP (HyperText Transfer Protocol) en mode GET ou en mode POST.  

Son protocole jumeau SRW (Search/Retrieve Web service), qui est basé,non pas sur l’usage d’URLs  mais sur l’offre de web services faisant transiter les requêtes http encapsulées dans du xml, utilise le protocole de communication SOAP (Simple Object Access Protocol).
Cette page est une traduction libre de la page du site de la Bibliothèque du Congrès : http://www.loc.gov/standards/sru/companionSpecs/transport.html.

Le protocole SRU via HTTP GET

Le client peut envoyer une requête SRU au serveur via le protocole HTTP en mode GET.
L’URL est construite et envoyée au serveur avec des paramètres prédéterminés dont la signification est prédéterminée. Si des caractères Unicode doivent être encodés, il y a des contraintes supplémentaires qui sont décrites ci-dessous.
La réponse doit être un flux XML conforme au schéma de réponse de l’opération. SRU par HTTP GET peut donc être décrit comme le cas le plus simple de XML par HTTP.


Exemple d’informations transmises sur le réseau

GET /voyager?version=1.2&operation=searchRetrieve&query=dinosaur HTTP/1.1 Host: z3950.loc.gov:7090

Syntaxe
Une requête SRU (quand elle est transportée par HTTP GET) est une URI décrite dans la recommandation RFC 3986 (Voir Note 1). En particulier, c’est une HTTP URL (telle que décrite dans la section 3.3 de la recommandation RFC 1738 ; il y a néanmoins des notes supplémentaires sur l’encodage des caractères ci-dessous). Dans la partie portant la recherche de l’URI, elle utilise l’encodage standard des paramètres et des valeurs sous la forme nomduparametre=valeur du parametre et séparation des paramètres par l’esperluette (&).
Les paramètres des diverses opérations, pour la partie portant la recherche de l’URL (l’information qui suit le point d’interrogation), sont décrits dans leur propre section.
 
Encodage
La procédure suivante est recommandée pour encoder les caractères, en particulier pour rendre utilisables les caractères UNICODE (caractères du Universal Character Set, ISO 10646) au-delà de U+007F, qui ne sont pas valides dans les URI. Ce n’est théoriquement utile que pour le paramètre de recherche (query) de l’opération searchRetrieve et le paramètre scanClause de l’opération Scan :
  1. Convertir la valeur en UTF-8.
  2. Utiliser le codage URL [ndt : Le codage consiste à remplacer les caractères spéciaux par le caractère « % » suivi du code ASCII du caractère à coder en notation hexadécimale] pour remplacer les caractères dans la valeur du paramètre (voir recommandation RFC 3986, section 2.1 « Percent-Encoding »).
  3. Construire l’URI à partir des noms de paramètres et des valeurs encodées.
À noter : dans l’étape 2, il est recommandé d’encoder avec % tous les caractères qui ne font pas partie de l’ensemble non-reservé des URI, c’est-à-dire tous sauf les caractères alphabétiques, les chiffres et les quatre caractères spéciaux suivants : tiret (-), point (.), tiret bas (_), tilde (~). Ce faisant, certains caractères peuvent être encodés en codage URL alors que ce n’est pas nécessaire. – Par exemple il n’est pas nécessaire d’encoder le point d’interrogation (?) présent dans une valeur de paramètre, mais c’est plus sûr. Dans le doute, utiliser le codage URL.
Exemple d’encodage
query=dc.title =/word kirkegård
Le nom du paramètre est « query » et la valeur est « dc.title =/word kirkegård »
À Noter que le premier « = » (suivant « query ») ne doit pas être encodé avec % parce qu’il est utilisé comme délimitation dans l’URI ; il ne fait pas partie du nom du paramètre ou de sa valeur. Le second « = » (précédant le slash « / ») doit être encodé car il fait partie de la valeur.
Les caractères suivants doivent être encodés :
  • le deuxième « = », encodé ainsi : « %3D » ;
  • le slash (/), encodé ainsi : « %2F » :
  • les espaces ( ), encodés ainsi : « %20 » ;
  • la lettre « å ». Sa représentation UTF-8 est C3A5, deux octets, et en conséquence, elle est représentée dans une URI comme deux caractères avec %, ainsi : « %C3%A5 ».
Le paramètre qui résulte de cet encodage et qui doit être envoyé au serveur sera :
query=dc.title%20%3D%2Fword%20kirkeg%C3%A5rd.


Traitement de l’information par le serveur

  1. Analyser et diviser la requête reçue à partir des caractères « ? », « & » et « = » en différents composants : l’URL de base, les noms des paramètres et leurs valeurs.
  2. Pour chaque paramètre 
  • Décoder les caractères d’échappement (en codage URL).
  • Traiter le résultat comme une chaîne UTF-8.
À Noter :
La recommandation RFC 1738 est remplacée par RFC 3986. Néanmoins RFC 1738 décrit le schéma d’URI ‘http:’ et RFC 3986 ne le fait pas, indiquant qu’un document autonome doit être écrit pour cela, mais celui-ci ne l’a pas encore été. Aussi n’y a-t-il pour l’instant aucune référence normative valide pour le schéma d’URI ‘http:’ et c’est à RFC 1738 qu’il faut faire référence. Quand une référence normative valide existera, elle sera citée ici.


Le protocole SRU via HTTP POST

Au lieu de construire une URL, les paramètres peuvent être envoyés au serveur par la méthode POST. L’en-tête du type de contenu (Content-type header) est « application/x www form urlencoded ». Il est différent de la valeur « text/xml » utilisée pour SRU par SOAP décrit ci-dessous, et peut être utilisé pour distinguer les deux modes de transport pour le même point d’accès.
POST a plusieurs avantages sur GET pour transmettre les requêtes au serveur :
  • les problèmes d’encodage URL des caractères disparaissent et un ensemble de caractères peut être spécifié dans l’en-tête de type de contenu (Content Type) ;
  • POST contourne le problème de longueur de la requête (des requêtes très longues pourraient générées des URL pour HTTP GET que certains serveurs ou clients ne seraient pas en mesure de gérer).
La réponse à SRU par POST est identique à la réponse à SRU par GET : un document XML.
Exemple d’informations transmises sur le réseau
POST /voyager HTTP/1.1
Host: z3850.loc.gov:7090
Content-type: application/x-www-form-urlencoded; charset=iso-8859-1 Content-length: 51
version=1.1&operation=searchRetrieve&query=dinosaur

Le protocole SRW via SOAP

SRW par SOAP est une passerelle vers la Recommandation SOAP (version originale en anglais, version française) du W3C. Via ce mode de transport, la requête est encodée en XML et enveloppée dans des éléments additionnels spécifiques à SOAP. La réponse est le même document XML que pour SRU par GET ou POST, mais enveloppé dans des éléments additionnels spécifiques à SOAP.
Spécifications
  • Les clients et les serveurs doivent obligatoirement supporter SOAP version 1.1 et peuvent supporter les versions 1.2 et au-delà. Cette spécification autorise toute la flexibilité possible dans la mise en œuvre.
  • Le type de service est « document/literal ».
  • Les messages doivent obligatoirement être linéaires et sans balise « multiref ».
  • L’en-tête HTTP SOAPAction peut être présent, mais n’est pas obligatoire. S’il est présent, sa valeur doit obligatoirement être une chaîne de caractères vide. Il est exprimé ainsi :
SOAPAction: «»
[ndt : Dans la liaison SOAP 1.2 sur HTTP, l’en-tête HTTP SOAPAction défini dans SOAP 1.1 a été retiré et un nouveau code d’état HTTP, 427, a été soumis à l’acceptation de l’IANA pour indiquer (à la discrétion du serveur HTTP d’origine) que l’application serveur requiert sa présence. Le contenu de l’ancien en-tête HTTP SOAPAction s’exprime maintenant par la valeur d’un paramètre (optionnel) «action», du type de media «application/soap+xml» signalé dans la liaison sur http, cf. http://www.w3.org/2002/07/soap-translation/soap12-part0.html#L4697].
  • Ainsi que spécifié dans la version 1.1 de SOAP, l’en-tête de type de contenu (Content-type) doit obligatoirement être « text/xml ». Pour la version 1.2, la valeur de l’en-tête doit obligatoirement être « application/soap+xml ». Les points d’accès supportant les deux versions de SOAP et SRU par POST doivent donc gérer trois en-têtes de type de contenu (Content-type).
Cette spécification cherche à être conforme aux recommandations Web Services Interoperability.
Différences de paramètres
Il y a des différences entre les paramètres qui peuvent être transportés par le « SOAP Binding » [ndt : voir la spécification http://www.w3.org/TR/ws-addr-soap/ du W3C].
  • Le paramètre « operation » de la requête ne doit pas être envoyé. L’opération est définie par la construction XML employée.
  • Le paramètre « stylesheet » de la requête ne doit pas être envoyé. SOAP interdit l’emploi de feuilles de style pour mettre en forme la réponse.