SRU : protocoles de transport

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.

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
   • a. Décoder les caractères d’échappement (en codage URL).
   • b. Traiter le résultat comme une chaîne UTF-8.

À Noter :
1. 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.

Avantages

• faciliter l’usage d’extensions structurées et de services web tel que mise en œuvre de serveurs mandataires (proxy) et routage de requête ;
• rendre possible l’emploi de meilleurs systèmes d’authentification.

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.

Exemple d'une requête SOAP