Cette section décrit le statut de ce document au moment
de sa publication. D'autres documents peuvent venir le remplacer. Une
liste des publications actuelles du W3C et la dernière révision de ce
rapport technique peuvent être trouvées dans l'index des rapports techniques du
W3C à l'adresse http://www.w3.org/TR/.
Voici la recommandation du 15 décembre 2004 de
l'"architecture du World Wide Web, volume Un". Après la revue de ce
document par des membres du W3C, des développeurs de logiciels, par
d'autres groupes du W3C et d'autres tiers intéressés, le Directeur l'a
approuvé comme recommandation du W3C. C'est un document stable, qui peut
servir en tant que documentation de référence ou être cité dans un autre
document. Le rôle du W3C, en produisant la recommandation, consiste à
attirer l'attention sur la spécification et à en promouvoir le large
déploiement. Elle participe à améliorer le fonctionnement et
l'interopérabilité du Web.
Ce document a
été produit par le groupe d'architecture technique [ndt. Technical Architecture
Group ou TAG], qui, selon la charte, maintient
une liste de
discussions au sujet de l'architecture. La portée de ce document
couvre un sous-ensemble utile de ces points. Il n'est pas prévu de les
traiter tous. Le TAG prévoit d'aborder les questions en suspens (ainsi que
les futures) maintenant que ce premier volume est édité en tant que
recommandation W3C. Un historique complet des changements de ce document est
disponible. Veuillez envoyer vos commentaires sur ce document à la liste
public-webarch-comments@w3.org (archives publiques). Les discussions techniques du TAG
ont lieu sur la liste www-tag@w3.org (archives publiques).
Ce
document a été produit dans le cadre de la politique IPR du W3C du document de processus de juillet
2001. Le TAG maintient une liste publique de révélations de brevet concernant ce
document ; cette page inclut également des instructions pour révéler
un brevet. Quiconque aurait connaissance de l'existence d'un brevet
susceptible de contenir une (ou plusieurs) revendication essentielle
concernant cette spécification devrait divulguer cette information,
conformément au chapitre 6 de la politique de brevetabilité du
W3C.
Le World Wide
Web (WWW ou plus simplement le
Web) est
un espace d'informations composé d'éléments caractérisés par identifiants
globaux, nommés des identifiants de ressource uniforme [ndt. Uniform
Resource Identifier](URI).
Les exemples, à l'image du scénario de voyage suivant, sont utilisés
tout au long de ce document pour illustrer le comportement typique d'agents Web
(personne ou logiciel agissant sur cet espace d'informations). Un agent
utilisateur représente un utilisateur. Le terme agent logiciel
comprend les serveurs, les proxies, les robots de recherche, les
navigateurs et les lecteurs multimédia.
Scénario
Alors qu'elle organise un
voyage à Mexico, Nadia lit “les informations sur le temps à Oaxaca:
'http://weather.example.com/oaxaca'” dans son superbe magazine de voyage.
Nadia est suffisamment expérimentée quant à l'utilisation du web pour
reconnaître que "http://weather.example.com/oaxaca" est un URI et qu'elle
obtiendra certainement l'information appropriée via son navigateur Web.
Lorsqu'elle saisit l'URI dans son navigateur :
- Le navigateur reconnaît que l'information saisie par Nadia est un
URI.
- Le navigateur exécute une action d'obtention de l'information. Il
se base sur la configuration du comportement à adopter face aux
ressources identifiées par le schéma d'URI "http".
- L'autorité responsable de "weather.example.com" fournit
l'information en réponse à cette demande.
- Le navigateur interprète la réponse, identifiée comme étant du
XHTML par le serveur et effectue des actions additionnelles de
récupération pour les graphiques intégrés ainsi que pour tout autre
contenu nécessaire.
- Le navigateur affiche l'information recherchée, qui inclut des
liens hypertextes vers d'autres informations. Nadia peut alors suivre
ces liens pour rechercher une information complémentaire.
Ce scénario illustre
les trois bases architecturales du web qui sont abordées dans ce document
:
Identification (§2).Les URI sont utilisés pour
identifier des ressources. Dans ce scénario relatif au voyage, la
ressource est un bulletin météo à Oaxaca mis à jour périodiquement.
L'URI est “http://weather.example.com/oaxaca”.
Interaction (§3). Les agents web communiquent en
s'appuyant sur des protocoles normalisés qui permettent des
interactions grâce à l'échange de messages conformes à une syntaxe et
une sémantique définies. En saisissant un URI dans un dialogue de
récupération ou en choisissant un lien hypertexte, Nadia indique à son
navigateur d'effectuer une action pour obtenir la ressource identifiée
par l'URI. Dans cet exemple, le navigateur envoie une requête HTTP GET
(qui fait partie du protocole HTTP) au serveur situé à l'adresse
"weather.example.com", via le port TCP/IP 80. Le serveur retourne
alors un message contenant ce qu'il détermine être une représentation
de la ressource au moment de sa génération. Notez que cet exemple est
spécifique à la navigation dans des informations hypertextes —
d'autres genres d'interaction sont possibles, que ce soit par
l'intermédiaire de navigateurs ou d'autres types d'agent Web. Notre
exemple sert à illustrer une interaction classique et non à définir la
gamme des interactions possibles, ni à restreindre l'étendu des façons
d'utiliser le Web qu'ont les agents.
Formats (§4). La plupart des protocoles utilisés pour
la récupération et/ou la soumission de représentation se servent d'une
séquence d'un ou plusieurs messages. Pris ensemble, ils forment un
certain volume de données et de métadonnées pour la représentation,
qui est utilisé pour son transfert entre les agents. Le choix du
protocole d'interaction induit des limites sur les formats des données
et des métadonnées de la représentation qui peut être transmise. HTTP,
par exemple, transmet typiquement un flux simple d'octets plus des
métadonnées. Il emploie l'information "Content-Type" et les champs
d'en-tête "Content-Encoding" pour l'identification à posteriori du
format de la représentation. Dans ce scénario, la représentation est
transférée en XHTML, comme l'indique le champ d'en-tête HTTP
"Content-Type". Ce dernier contient, en effet, le type de média
Internet "application/xhtml+xml". Il indique que les données de la
représentation peuvent être traitées selon les spécifications de
XHTML.
Le navigateur de Nadia est
configuré et programmé pour interpréter la réception d'une
représentation ayant le type "application/xhtml+xml" comme étant une
instruction de formatage du contenu de cette représentation selon le
modèle de rendu XHTML. Il en va de même pour toutes les interactions
complémentaires (telles que les requêtes vers des feuilles externes ou
encore des images intégrées) réclamées par la représentation. Dans ce
scénario, les données de la représentation XHTML reçues, suite à la
demande initiale, indiquent par ailleurs au navigateur de Nadia de
récupérer et d'afficher les cartes météo incluses. Chacune est
identifiée par un URI et cause, de ce fait, une action supplémentaire
de récupération. Elle engendre d'autres représentations qui sont
traitées par le navigateur selon leurs propres formats de données (par
exemple, "application/svg+xml" indique le format de données de SVG).
Ce processus continue jusqu'à ce que tous les formats de données aient
été rendus. Le résultat de tous ces traitements, une fois que le
navigateur a atteint un état stable répondant à l'action initiale
demandée par Nadia, est généralement désigné par le terme de "Page
Web".
La figure suivante montre les
relations entre un identifiant, une ressource et une représentation.
Dans la suite de ce document, nous soulignerons les points importants
d'architecture ayant un rapport avec les identifiants Web, les protocoles
et les formats. Nous discuterons également des principes généraux d'architecture (§5) majeurs et comment
ils s'appliquent au Web.
Ce document décrit les propriétés que nous désirons pour le
web et les choix de conception faits pour les mettre en oeuvre. Il
favorise la réutilisation de standards existants lorsqu'ils sont
appropriés et donne des conseils sur la façon d'innover en étant en
conformité avec l'architecture du Web.
Les termes DOIT (DOIVENT), NE DOIT (DOIVENT) PAS, DEVRA
(DEVRONT), NE DEVRA (DEVRONT) PAS et PEUT (PEUVENT) sont utilisés dans les
principes, contraintes et bonnes pratiques. Ils sont décrits dans le
document [RFC2119].
Ce document n'inclut pas de dispositions de conformité pour
les raisons suivantes :
- La conformité logicielle se doit d'être si diverse qu'il ne semble
pas utile de pouvoir se référer à la classe de conformité des agents
logiciels.
- Certaines notes de bonnes pratiques concernent les personnes. Les
spécifications, quant à elles, définissent généralement la conformité
pour le logiciel et non pour les personnes.
- Nous ne croyons pas que l'ajout d'une section ayant pour objet la
conformité est susceptible d'augmenter l'utilité du document.
Le but de ce document est d'informer à propos des
discussions liées à l'architecture du Web. Le public visé par ce document
inclut :
- Les participants aux activités du W3C,
- D'autres groupes et personnes concevant des technologies devant
être intégrées au Web,
- Les personnes mettant en oeuvre les spécifications du W3C,
- Les auteurs et éditeurs de contenu Web.
Note: Ce document ne fait
aucune distinction formelle entre les termes "langage" et "format". Le
contexte détermine l'utilisation de chacun. L'expression "concepteur de
spécification" englobe les notions de conception de langage, de format et
de protocole.
Ce document présente
l'architecture générale du Web. D'autres groupes à l'intérieur et à
l'extérieur du W3C se concentrent également sur des aspects spécifiques de
l'architecture du Web, comme l'accessibilité, l'assurance qualité,
l'internationalisation, l'indépendance des dispositifs et les services
Web. La section concernant les spécifications liées à l'architecture (§7.1) fait
référence à ces spécifications.
Ce
document essaie d'atteindre un équilibre entre brièveté et précision tout
en illustrant par des exemples. Les conclusions du TAG
sont des documents d'information qui complètent le présent document en
fournissant plus de détails sur des points précis. Ce document inclut
quelques extraits de ces conclusions. Ces documents complémentaires
évoluant indépendamment, celui-ci inclut des références aux conclusions
approuvées par le TAG. Pour les autres discussions du TAG non approuvés
mais abordés ici, les références sont incluses dans la liste des
publications du TAG.
Beaucoup
d'exemples dans ce document, impliquant la participation d'une personne,
font l'hypothèse d'un modèle familier d'interaction avec le Web (illustré
au début de l'introduction) dans lequel une personne suit un lien par
l'intermédiaire d'un agent utilisateur, celui-ci récupère et présente les
données, puis l'utilisateur suit un autre lien, etc... Ce document
n'aborde aucun autre modèle d'interaction tel que la navigation avec la
voix (voir, par exemple, [VOICEXML2]). Le choix du modèle d'interaction peut avoir
un impact sur le comportement attendu d'un agent. Par exemple, lorsqu'un
agent utilisateur graphique, s'exécutant sur un ordinateur portable ou sur
un dispositif mobile, rencontre une erreur, il peut la rapporter
directement à l'utilisateur par des manifestations visuelles et sonores et
lui présenter des options pour la résoudre. D'autre part, lorsque
quelqu'un navigue sur le web via la voix et ne dispose que d'un retour
sonore, l'arrêt du dialogue pour attendre une information provenant de
l'utilisateur peut réduire sa facilité d'utilisation. Il est en effet
vraiment facile de "perdre le fil" en navigant uniquement avec une sortie
audio. Ce document ne traite pas de la façon dont les principes, les
contraintes et les bonnes pratiques identifiés ici s'appliquent dans tous
les contextes d'interaction.
Les points importants dans ce document sont classés par
catégorie comme suit :
- Principe
- Un principe architectural est une règle fondamentale qui
s'applique à un grand nombre de situations et de variables. Parmi ces
principes architecturaux se trouvent la "séparation des problèmes",
l'"interface générique", la "syntaxe auto-descriptive", une
"sémantique évidente", l'"effet de réseau" (la loi de Metcalfe) et la
loi d'Amdahl : "la vitesse d'un système est limitée par son composant
le plus lent".
- Contrainte
- Dans la conception du Web, certains choix, comme les noms des
éléments
p et li en HTML, le choix du
caractère deux points (:) dans les URI ou encore le regroupement des
bits en grappe de huit (octets) sont arbitraires. Si
paragraph avait été choisi à la place de p
ou l'astérisque (*) au lieu des deux points, le résultat à grande
échelle aurait été, très probablement, identique. Ce document se
concentre sur des choix de conception plus fondamentaux : les choix de
conception qui mènent aux contraintes, c'est-à-dire des restrictions
dans le comportement ou l'interaction dans le système. Ces contraintes
peuvent être imposées pour des raisons techniques, politiques ou
autres afin de réaliser des propriétés souhaitées dans le système,
comme l'accessibilité, la portée globale, la relative facilité
d'évolution, l'efficacité et l'extensibilité dynamique.
- Bonne
pratique
- Les bonnes pratiques, énoncées par des développeurs de logiciel,
les auteurs, les responsables de site, les utilisateurs et les
concepteurs de spécification, augmentent la valeur du Web.
Pour sa
communication interne, une communauté s'accorde (jusqu'à un degré
raisonnable) sur un ensemble de termes et sur leur signification. Un des
buts du Web, depuis sa genèse, a été d'établir une communauté globale dans
laquelle n'importe quelle partie peut partager une information avec
n'importe quelle autre partie. À dessein d'y parvenir, le web se sert d'un
système simple et global d'identification : l'URI. Les URI sont une pierre
angulaire de l'architecture du Web, fournissant une identification commune
à travers le Web. La portée globale des URI favorise les "effets de
réseau" à grande échelle : la valeur d'un identifiant augmente à mesure
qu'il est utilisé de façon consistante (par exemple, plus il est employé
dans les liens
hypertextes (§4.4)).
Principe: Identifiants globaux
Le nommage global conduit
aux effets de réseau global.
Ce
principe date au moins du temps où Douglas Engelbart effectuait un travail
séminal sur les systèmes hypertextes ouverts ; voir la section chaque objet accessible dans le document [Eng90].
Le choix de la syntaxe pour
les identifiants globaux est quelque peu arbitraire ; l'important reste
leur portée globale. L'identifiant de
ressource uniforme, [URI], a été
déployé avec succès depuis la création du Web. Il y a des avantages
substantiels à participer au réseau existant d'URI, comme l'établissement
de liens, de signets, de mise en mémoire cache et l'indexation par des
moteurs de recherche. Par ailleurs, créer un nouveau système
d'identification qui possède les mêmes propriétés que les URI, induit un
coût non négligeable.
Bonne pratique : Identifier à l'aide
d'URI
Pour
tirer parti du web global et en augmenter la valeur, les agents devraient
fournir des URI comme identifiants de ressources.
Une ressource devrait avoir un URI associé à
partir du moment où une tierce partie peut vouloir créer un lien
hypertexte vers elle, faire ou réfuter des affirmations à son sujet,
rechercher ou mettre en mémoire cache une représentation la concernant,
l'inclure en partie ou dans son ensemble en la référençant dans une autre
représentation, l'annoter ou encore effectuer d'autres opérations. Les
développeurs de logiciels devraient attendre une certaine utilité du
partage d'URI à travers des applications, même si elle n'est pas évidente
de prime abord. Les conclusions du TAG sur "les
URI, la possibilité d'adressage et l'utilisation du HTTP GET et POST
[URIs, Addressability, and the use of HTTP GET and POST]"
montrent les avantages complémentaires et la possibilité d'adressage par
les URI.
Note: Les
schémas d'URI (tels que les spécifications du schéma "ftp") emploient le
terme "désigner" alors que ce document utilise "identifier".
Par conception, un URI identifie une ressource. Nous ne limitons pas la
portée de ce qui pourrait être une ressource. Le terme "ressource" est
employé dans un sens général pour qualifier tout ce qui pourrait être
identifié par un URI. Il est courant, sur le web hypertexte, de décrire
des pages Web, des images, des catalogues de produits, etc... comme étant
des “ressources”. Les caractéristiques essentielles qui différencient ces
ressources peuvent être empaquetées dans un message. Nous identifions cet
ensemble par l'expression “ressources de
l'information”.
Ce document
est un exemple de ressources d'information. Il se compose de mots, de
symboles de ponctuation, de graphiques et d'autres objets qui peuvent être
encodés en une séquence de bits, avec un degré variable de fidélité. En
principe, tout ce qui compose l'essentiel de l'information de ce document
peut transféré dans un message, dont la valeur ajoutée est une représentation de ce
document.
Cependant, notre utilisation
du terme ressource est intentionnellement plus large. D'autres choses,
comme des voitures et des chiens (et, si vous avez imprimé ce document sur
des feuilles de papier, l'objet que vous tenez dans vos mains), sont
également des ressources. Mais il ne s'agit pas de ressources
d'information, car leur essence n'est pas de l'information. Même s'il est
possible de décrire un grand nombre de choses au sujet d'une voiture ou
d'un chien dans une séquence de bits, la somme de ces choses sera toujours
une approximation du caractère essentiel de la ressource.
Nous définissons le terme “ressource de
l'information” car nous observons qu'il est utile lors des discussions à
propos de la technologie web et peut l'être lors de l'élaboration de
spécifications pour des équipements construits pour un usage sur le
Web.
Contrainte : Les URI identifient une ressource
simple
Assignez des URI distincts à des ressources distinctes.
Puisque la portée d'un URI est globale, la
ressource identifiée par un URI ne dépend pas du contexte dans lequel elle
apparaît (voir également la section au sujet de l'identification indirecte
(§2.2.3)).
Un [URI] est un accord sur la façon dont la communauté
Internet assigne des noms et les associe aux ressources qu'ils
identifient. Les URI sont divisés en schémas (§2.4) qui définissent, par l'intermédiaire de
leur spécification, le mécanisme par lequel des identifiants spécifiques
au schéma sont associés aux ressources. Par exemple, le schéma d'URI
"http" ([RFC2616]) utilise des
serveurs DNS et HTTP, basés sur TCP, afin d'attribuer et de résoudre un
identifiant. Par conséquent, les identifiants tels que
"http://example.com/somepath#someFrag" signifie souvent, au vu de
l'expérience de la communauté, l'exécution d'une requête HTTP GET à partir
de l'identifiant et si la réponse est correcte, l'interprétation de la
réponse comme étant une représentation de la ressource identifiée. (voir
également les identifiants de fragment
(§2.6)). Naturellement, une action de récupération comme un GET n'est
pas la seule manière d'obtenir des informations au sujet d'une ressource.
On pourrait également éditer un document qui prétend définir la
signification d'un URI particulier. Ces autres sources d'information
peuvent suggérer des significations pour de tels identifiants, cependant
l'observation de ces suggestions relève d'une politique locale.
De la même façon que l'on pourrait souhaiter se
référer à une personne par l'intermédiaire de différents noms (par son nom
et son prénom, seulement par prénom, par un surnom lié au sport, par un
surnom romantique et ainsi de suite), l'architecture du web permet
d'associer plus d'un URI à une ressource. Les URI qui identifient la même
ressource sont nommés des alias d'URI. La section les
concernant (§2.3.1) revient sur
certains coûts potentiels relatifs à la création d'URI multiples pour la
même ressource.
Plusieurs sections de ce
document abordent la relation entre les URI et les ressources, comme :
Par conception, un URI identifie une ressource.
L'utilisation d'un même URI pour identifier directement différentes
ressources produit une collision d'URI. Une collision
induit souvent un coût dans la communication relatif à l'effort exigé par
la levée des ambiguïtés.
Supposons, par
exemple, qu'une organisation se sert d'un URI pour se référer au film
"The Sting" et qu'une autre organisation emploie le même URI
pour se rapporter à un forum de discussion au sujet de ce film. Pour un
tiers, familier des deux organismes, cette collision crée une confusion au
sujet de ce que l'URI identifie, diminuant ainsi la valeur de cet URI. Par
exemple, si quelqu'un voulait parler de la date de création de la
ressource identifiée par l'URI, il ne serait pas clair de savoir si elle
signifie "quand le film a été créé" ou "quand le forum de discussion au
sujet du film a été créé."
Des solutions
sociales et techniques ont été conçues pour aider à éviter la collision
d'URI. Cependant, le succès ou l'échec de ces différentes approches dépend
de l'importance du consensus qui existe dans la communauté Internet à
propos du respect des spécifications les définissant.
La section sur l'attribution d'URI (§2.2.2) examine des approches pour
établir la source d'informations appropriée permettant de définir quelle
ressource est identifiée par un URI.
Les
URI sont parfois utilisés pour des identifications indirectes (§2.2.3). Cela ne conduit pas
nécessairement à des collisions.
L'attribution d'URI est le processus consistant à associer
un URI à une ressource. L'attribution peut tout aussi bien se faire par
les propriétaires de ressource ou par d'autres parties. L'important est
d'éviter les collisions d'URI
(§2.2.1).
La propriété d'URI est une relation
entre un URI et une entité sociale, telle qu'une personne, une
organisation ou une spécification. La propriété d'URI procure certains
droits à l'entité sociale concernée, comme :
- la possibilité de transmettre, à un tiers, la propriété de
certaines ou de toutes les URI possédés (délégation) et
- d'associer une ressource à un URI possédé (attribution
d'URI).
Par convention sociale, la propriété
d'URI est déléguée depuis le référentiel des schémas d'URI de l'IANA [IANASchemes], lui-même une entité
sociale, aux spécifications de schémas d'URI enregistrés auprès de l'IANA.
Certaines spécifications de schémas d'URI délèguent la propriété à des
référentiels subordonnés ou à d'autres propriétaires explicitement nommés,
qui peuvent, de la même façon déléguer cette propriété. Dans le cas d'une
spécification, la propriété appartient finalement à la communauté qui
maintient cette spécification.
L'approche adoptée pour le schéma d'URI "http", par
exemple, suit le modèle selon lequel la communauté Internet délègue la
responsabilité, par l'intermédiaire du référentiel de schémas d'URI de
l'IANA et du DNS, au moyen d'un ensemble d'URI ayant un préfixe commun, à
un propriétaire particulier. La forte confiance du web dans le répertoire
central DNS est une des conséquences de cette approche. Une approche
différente est adoptée par le schéma de la syntaxe URN [RFC2141] qui délègue la propriété des différentes parties
de l'espace d'URN aux spécifications de l'espace de noms URN, qui sont
elles-mêmes enregistrées dans un référentiel d'identifiants d'espace de
noms, maintenu par l'IANA.
Les
propriétaires d'URI sont chargés d'éviter l'attribution d'URI équivalents
à des ressources multiples. Ainsi, si des spécifications de schéma d'URI
prévoient la délégation d'un URI ou d'ensembles organisés d'URI, il est
nécessaire de prendre les mesures visant à s'assurer que la propriété
réside finalement entre les mains d'une entité sociale unique. Permettre
des propriétaires multiples augmente la probabilité de collisions
d'URI.
Les propriétaires d'URI peuvent
organiser ou déployer une infrastructure afin de s'assurer que les
représentations des ressources associées sont disponibles et, le cas
échéant, que l'interaction avec la ressource est possible par le biais
d'échange de représentations. La gestion [responsable] des
représentations (§3.5) par les propriétaires d'URI est source
d'attentes sociales. Les autres implications sociales concernant la
propriété d'URI ne sont pas abordées ici.
Voir les discussions du TAG siteData-36, concernant l'expropriation d'autorité de
nommage.
Certains
schémas utilisent d'autres techniques que la propriété déléguée afin
d'éviter les collisions. Par exemple, la spécification pour le schéma
d'URL de données (sic) [RFC2397]
indique qu'une ressource identifiée par un schéma d'URI de données ne
possède qu'une seule représentation possible. Les données de la
représentation composent l'URI qui identifie cette ressource. Ainsi, la
spécification elle-même détermine comment les URI de données sont
attribués ; aucune délégation n'est possible.
D'autres schémas (comme "news:comp.text.xml") se basent sur
un processus social.
Énoncer que l'URI "mailto:nadia@example.com" identifie à la
fois une boîte aux lettres Internet et Nadia, introduit une collision
d'URI. Par contre, l'URI peut servir à identifier indirectement Nadia. Et,
c'est de cette façon que les identifiants sont généralement employés.
En écoutant les actualités, il est possible
d'entendre un reportage sur la Grande-Bretagne commençant ainsi :
"Aujourd'hui, le 10 Downing Street a annoncé une série de nouvelles
mesures économiques". En général, le "10 Downing Street" identifie la
résidence officielle du premier ministre anglais. Dans ce contexte, le
journaliste emploie cette formule (comme la rhétorique le permet) pour
identifier indirectement le gouvernement britannique. De la même façon,
les URI identifient des ressources, mais elles peuvent également servir,
dans bien des cas, à désigner indirectement d'autres ressources. Les
politiques d'attribution adoptées de façon globale font de certains URI
des identifiants généraux. La politique locale, quant à elle, établit ce
qu'ils identifient de façon indirecte.
Supposons que nadia@example.com soit l'adresse
de courrier électronique de Nadia. Les organisateurs d'une conférence à
laquelle elle assiste pourraient employer "mailto:nadia@example.com" pour
se référer indirectement à elle (par exemple, en se servant de l'URI comme
clef dans leur base de données des participants à la conférence). Cela ne
constitue pas un cas de collision d'URI.
Les URI, qui sont identiques au caractère
près, se réfèrent à la même ressource. L'architecture du web permet
d'associer plusieurs URI à une ressource donnée. Ainsi deux URI non
identiques (caractère pour caractère) peuvent se rapporter à une même
ressource. Des URI différents ne se rapportent donc pas nécessairement à
des ressources différentes. Cela induit cependant un coût informatique
plus élevé pour déterminer que des URI différents se rapportent à la même
ressource.
Pour réduire le risque de
cas faussement négatif (c'est-à-dire, une conclusion erronée sur le fait
que deux URI ne se rapportent pas à la même ressource) ou de cas
faussement positif (c'est-à-dire, une conclusion inexacte sur le postulat
que deux URI se rapportent effectivement à la même ressource), certaines
spécifications décrivent des tests d'équivalence complémentaires à la
comparaison caractère par caractère. Les agents qui tirent des conclusions
en se basant sur des comparaisons non approuvées par les spécifications
concernées engagent leur responsabilité pour tout problème potentiel
résultant ; pour plus d'informations sur le comportement responsable à
adopter face à des conclusions non autorisées, voir la section sur la gestion des erreurs
(§5.3). La section 6 des [URI] fournit
plus d'informations sur la comparaison d'URI et sur la réduction du risque
de jugement faussement négatif et positif.
Voir également l'affirmation que deux URI identifient la même ressource
(§2.7.2).
Bien que les alias d'URI présentent des avantages (comme la
flexibilité en matière de nommage), il est bon de considérer également
leurs coûts. Les alias d'URI sont nocifs quand ils divisent un ensemble
(le Web) composé de ressources liées entre elles. Un corollaire du
principe de Metcalfe (l'"effet de réseau") veut que la valeur d'une
ressource donnée peut être mesurée par le nombre et la valeur des autres
ressources dans son voisinage réseau, c'est-à-dire, les ressources qui
font un lien vers elle.
Les alias posent
un problème. Si une même ressource est désignée, grâce à un URI donné, par
la moitié d'un ensemble et qu'elle est également désignée à l'aide d'un
deuxième URI par la seconde moitié de cet ensemble, une division se crée.
Non seulement la ressource perd de sa valeur en raison de cette fracture,
mais c'est l'ensemble des ressources qui se dévalue en raison de l'absence
des relations qui auraient dû exister entre les ressources faisant des
références.
Bonne pratique : Éviter les alias
d'URI
Un
propriétaire d'URI NE DEVRAIT PAS associer arbitrairement différents URI à
la même ressource.
Les
consommateurs d'URI ont également un rôle à jouer en s'assurant de la
cohérence de l'URI. Par exemple, lors de la transcription d'un URI, les
agents ne devraient pas encoder, de façon gratuite, les caractères avec
des pourcents. Le terme "caractère" se rapporte à des caractères d'URI
(voir la définition dans la section 2 des [URI]). L'encodage avec des pourcents est discuté dans la
section 2.1 de cette spécification.
Bonne pratique : Usage consistant des
URI
Un
agent qui reçoit un URI DEVRAIT se référer à la ressource associée en
utilisant le même URI, caractère-par-caractère.
Lorsqu'un URI devient monnaie courante, le propriétaire de l'URI devrait
utiliser des techniques se basant sur le protocole, telles que la
redirection côté serveur, pour relier les deux ressources. Le support, par
son propriétaire, de la redirection d'un alias d'URI vers l'URI "officiel"
bénéficie à toute la communauté. Pour plus d'informations sur la
redirection, voir la section 10.3, "Redirection", dans la [RFC2616]. Voir également [CHIPS] pour une discussion sur certaines
des meilleures pratiques pour les administrateurs de serveur.
Le phénomène d'alias
d'URI ne se produit que lorsque plus d'un URI est utilisé pour identifier
la même ressource. Le fait que différentes ressources possèdent parfois la
même représentation ne fait pas pour autant de ces URI des alias.
Scénario
Sur son site Web, Dirk voudrait ajouter un lien au site
donnant la météo à Oaxaca. Il se sert alors de l'URI
http://weather.example.com/oaxaca et étiquette son lien "temps à Oaxaca,
le 1 août 2004". Nadia précise à Dirk qu'il se trompe vis-à-vis
de la pertinence de l'URI employé. La politique de ce site définit que
l'URI en question identifie le temps courant à Oaxaca (quel que soit le
jour) et non le temps du 1 août. Naturellement, le premier jour d'août
2004, le lien de Dirk sera correct. Mais le reste du temps, il induira en
erreur les visiteurs de son site Web. Nadia signale à Dirk que ce site
météo fournit un URI différent, disponible de manière permanente et
assigné à une ressource décrivant le temps du 1 août 2004.
Dans cette histoire, il y a deux
ressources : "le temps courant à Oaxaca" et "le temps à Oaxaca le
1 août 2004". Le site donnant la météo à Oaxaca assigne deux URI
à ces deux ressources différentes. Le 1 août 2004, les
représentations pour ces ressources sont identiques. Le fait que le
déréférencement de deux URI différents produit des représentations
identiques ne permet pas de conclure que les deux URI sont des alias.
Dans l'URI "http://weather.example.com/", le terme "http"
qui précède les deux points (":") nomme un schéma d'URI. Chacun de ces
schémas d'URI possède une spécification particulière qui détaille comment
les identifiants de ce schéma sont alloués et sont associés à une
ressource. La syntaxe d'URI est ainsi un système d'appellation fédéré et
extensible dans lequel la spécification de chaque schéma peut limiter la
syntaxe et la sémantique des identifiants du schéma.
Exemples d'URI provenant de divers schémas :
- mailto:joe@example.org
- ftp://example.org/aDirectory/aFile
- news:comp.infosystems.www
- tel:+1-816-555-1212
- ldap://ldap.example.org/c=GB?objectClass?one
- urn:oasis:names:tc:entity:xmlns:xml:catalog
Même si l'architecture du web permet
la définition de nouveaux schémas, une telle introduction est coûteuse. De
nombreux aspects du traitement d'URI sont dépendants d'un schéma
particulier. Par ailleurs, un grand nombre de logiciels déployés traite
déjà les schémas d'URI bien connus. L'introduction d'un nouveau schéma
d'URI exige le développement et le déploiement non seulement de logiciels
clients pouvant manipuler le schéma, mais également d'agents auxiliaires
tels que des passerelles, des proxies et des systèmes de mémoire cache.
Voir la [RFC2718] pour d'autres
considérations et les coûts liés à la conception de schéma d'URI.
En raison de ces coûts, si un schéma d'URI
existant satisfait les besoins d'une application, les concepteurs
devraient l'employer plutôt que d'en inventer un.
Bonne pratique : Réutiliser les schémas
d'URI
Une
spécification DEVRAIT réutiliser un schéma d'URI existant (plutôt que d'en
créer un nouveau) lorsqu'il fournit les propriétés désirées pour les
identifiants et leurs relations aux ressources.
Considérons notre scénario de voyage : Est-ce que l'agent fournissant des
informations au sujet du temps à Oaxaca devrait enregistrer un nouveau
schéma d'URI "weather" pour identifier des ressources liées au temps ?
Elles pourraient alors servir à des URI comme
"weather://travel.example.com/oaxaca". Quand un agent logiciel déréférence
ce type d'URI, si l'action réelle est un HTTP GET, servant à obtenir une
représentation de la ressource, alors un URI "http" devrait suffire.
L'IANA
(Internet Assigned Numbers Authority) maintient un référentiel [IANASchemes] des correspondances
entre les noms de schéma d'URI et leur spécification. Par exemple, ce
référentiel indique que le schéma "http" est défini par la [RFC2616]. Le processus pour enregistrer
un nouveau schéma d'URI est, quant à lui, défini par la [RFC2717].
Les schémas d'URI non enregistrés NE DEVRAIENT PAS être
utilisés pour un certain nombre de raisons :
- En général, il n'y a pas de moyen reconnu pour accéder à la
spécification du schéma,
- Le schéma peut être utilisé par d'autres dans des buts
différents,
- Il ne faut pas s'attendre à ce qu'un logiciel généraliste puisse
faire quoi que ce soit d'utile avec ce type de schéma d'URI, mise à
part la comparaison d'URI.
Une motivation malencontreuse qui
pousse à enregistrer un nouveau schéma d'URI consiste à permettre à un
agent logiciel de lancer une application particulière lorsqu'il obtient
une représentation. Il est possible d'obtenir le même résultat, mais à
moindre coût, en s'appuyant plutôt sur le type de la représentation,
permettant alors l'utilisation de protocoles et de mises en oeuvre de
transfert existants.
Même si un format
inconnu empêche un agent de traiter des données liées à une
représentation, il peut néanmoins la récupérer. Les données peuvent
contenir des informations suffisantes pour permettre à un utilisateur ou à
un agent utilisateur d'en faire une certaine utilisation. A contrario
lorsqu'un agent ne sait pas traiter un nouveau schéma d'URI, il ne peut
pas en obtenir de représentation.
Lors
de la conception d'un nouveau format de données, le mécanisme de choix
pour favoriser son déploiement sur le web est l'utilisation du type de
média Internet (voir les types
de représentation et les types de média Internet (§3.2)). Les types de
média fournissent également des moyens pour construire de nouvelles
applications d'information, comme décrit dans les futures directions pour les
formats de données (§4.6).
Il est tentant de deviner la
nature d'une ressource en examinant un URI qui l'identifie. Cependant, le
web est construit de telle sorte que les agents communiquent l'état des
ressources d'information à l'aide de représentations et non via des identifiants. En général,
il n'est pas possible de déterminer le type de la représentation d'une
ressource en examinant un URI de cette ressource. Par exemple, le ".html"
terminant "http://example.com/page.html" ne fournit aucune garantie sur le
fait que la représentation de la ressource identifiée sera servie avec le
type de média Internet "text/html". L'éditeur est libre d'assigner des
identifiants et de définir comment ils sont servis. Le protocole HTTP ne
contraint pas le type de média Internet à se baser sur le composant chemin
de l'URI. Le propriétaire de l'URI est libre de configurer le serveur pour
renvoyer une représentation en utilisant par exemple PNG ou tout autre
format de données.
L'état d'une
ressource peut évoluer dans le temps. Exiger d'un propriétaire d'URI de
publier un nouvel URI pour chaque changement d'état de la ressource
conduirait à un nombre significatif de références cassées. Pour apporter
plus de robustesse, l'architecture du web met en avant l'indépendance
entre un identifiant et l'état de la ressource identifiée.
Bonne pratique : Opacité d'URI
Les agents, utilisant des
URI, NE DEVRAIENT PAS essayer de déduire des propriétés à partir de la
ressource référencée.
En
pratique, un nombre restreint de déductions, explicitement autorisées par
les spécifications sous-jacentes, peuvent être faites. Certaines de ces
déductions sont abordées dans la section qui détaille l'obtention d'une
représentation (§3.1.1).
L'URI
d'exemple utilisé dans le scénario de
voyage ("http://weather.example.com/oaxaca") suggère à un lecteur
(humain) que la ressource identifiée a un rapport avec le temps à Oaxaca.
Un site indiquant le temps à Oaxaca pourrait tout aussi bien être
identifié par l'URI "http://vjc.example.com/315". Par ailleurs, l'URI
"http://weather.example.com/vancouver" pourrait identifier la ressource
"mon album photo".
D'un autre côté,
l'URI "mailto:joe@example.com" indique que l'URI se réfère à une boîte aux
lettres. La spécification du schéma d'URI "mailto" autorise les agents à
déduire que les URI de cette forme identifient des boîtes aux lettres
Internet.
Certaines autorités
d'attribution d'URI documentent et éditent leur politique d'assignation
d'URI. Pour plus d'informations sur l'opacité d'URI, voir les discussions
du TAG metaDataInURI-31 et siteData-36.
Scénario
Lorsque Nadia lit le document XHTML qu'elle a reçu, comme
étant une représentation de la ressource identifiée par
"http://weather.example.com/oaxaca", elle constate que l'URI
"http://weather.example.com/oaxaca#weekend" se réfère à la partie de la
représentation qui donne des informations sur les perspectives du
week-end. Cet URI inclut l'identifiant de fragment "weekend" (la chaîne de
caractères après le "#").
Le composant identifiant de fragment d'un URI permet
l'identification indirecte d'une ressource secondaire en se
référant à une ressource primaire et à une information d'identification
additionnelle. La ressource secondaire peut être une certaine partie ou un
sous-ensemble de la ressource primaire, une certaine vue sur des
représentations de la ressource primaire ou une autre ressource définie ou
décrite par ces représentations. Les termes "ressource primaire" et
"ressource secondaire" sont définis dans la section 3.5 du document [URI].
Les
termes "primaire" et "secondaire" dans ce contexte ne limitent pas la
nature de la ressource (ce ne sont pas des classes). Dans ce contexte,
primaire et secondaire indiquent simplement qu'il existe une relation
entre les ressources qui forment un URI : l'URI avec un identifiant de
fragment. Toute ressource peut être identifiée comme étant une ressource
secondaire. Elle pourrait également être identifiée en utilisant un URI
sans identifiant de fragment. Une ressource peut être identifiée comme
ressource secondaire par l'intermédiaire d'URI multiples. Le but de ces
termes est de permettre de discuter de la relation entre de telles
ressources et non de se limiter à la nature d'une ressource.
L'interprétation des identifiants de fragment
est abordée dans la section concernant les types de représentation et sémantique de l'identifiant de
fragment (§3.2.1).
Voir la
discussion du TAG abstractComponentRefs-37, qui concerne l'utilisation des
identifiants de fragment avec des espaces de noms pour l'identification
des composants abstraits.
Il reste des questions en suspens concernant les
identifiants sur le Web.
L'intégration des
identifiants internationalisés (c'est-à-dire, composés de caractères
outrepassant ceux permis par les [URI])
dans l'architecture web est un sujet important et ouvert. Voir la
discussion du TAG, IRIEverywhere-27, abordant le travail mené à propos de
cette problématique.
Les technologies sémantiques naissantes, comme "le Langage
d'Ontologie Web (OWL)" [OWL10],
définissent des propriétés RDF, telles que sameAs pour
affirmer que deux URI identifient la même ressource ou
inverseFunctionalProperty pour le suggérer.
La
communication, entre des agents au travers d'un réseau, au sujet de
ressources implique des URI, des messages et des données. Les protocoles
du web (tels que HTTP, FTP, SOAP, NNTP et SMTP) sont basés sur l'échange
de messages. Un message peut inclure des données, mais
aussi des métadonnées (comme les en-têtes HTTP "Alternates" et "Vary"), au
sujet d'une ressource, des données du message et du message lui-même (à
l'image de l'en-tête HTTP "Transfer-encoding"). Un message peut même
inclure des métadonnées relatives aux métadonnées du message (pour la
vérification de l'intégrité du message, par exemple).
Scénario
Nadia suit un lien hypertexte, dont le nom est "image
satellite". Elle s'attend ainsi à obtenir une photo satellite de la région
d'Oaxaca. Le lien vers l'image satellite est un lien XHTML codé ainsi
<a href="http://example.com/satimage/oaxaca">image
satellite</a>. Le navigateur de Nadia analyse l'URI et
détermine que son schéma est
"http". La configuration du navigateur déduit la façon de localiser
l'information identifiée. Ce peut être par l'intermédiaire d'une zone de
cache, contenant des actions de récupération déjà effectuées, par le
contact d'un intermédiaire (tel qu'un serveur proxy) ou par accès direct
au serveur identifié par une partie de l'URI. Dans cet exemple, le
navigateur ouvre une connexion réseau sur le port 80 du serveur situé à
l'adresse "example.com". Puis, il envoie un message "GET", comme le
protocole HTTP le spécifie, pour demander une représentation de la
ressource.
Le serveur envoie alors un
message de réponse au navigateur, en conformité une nouvelle fois avec le
protocole HTTP. Le message se compose de plusieurs en-têtes et d'une image
JPEG. Le navigateur lit les en-têtes, déduit du champ "Content-Type" que
le type de média Internet de la représentation est "image/jpeg". Il lit
alors la séquence d'octets qui composent les données de la représentation
et affiche l'image.
Cette section décrit les principes et les contraintes
d'architecture concernant les interactions entre les agents. Il s'agit de
sujets comme les protocoles réseau et les modèles d'interaction, ainsi que
les interactions entre le web en tant que système et les personnes qui
s'en servent. Le fait que le web soit un système fortement réparti affecte
les contraintes et les suppositions liées à l'architecture au sujet des
interactions.
Les agents peuvent
utiliser un URI pour accéder à la ressource référencée. C'est le concept
de déréférencement
d'URI. L'accès peut prendre diverses formes, comme l'obtention
d'une représentation de la ressource (par exemple, en utilisant un GET ou
un HEAD HTTP), l'ajout ou la modification une représentation de la
ressource (par exemple, en utilisant un POST ou un PUT HTTP, qui dans
certains cas peut changer l'état réel de la ressource si les
représentations soumises sont interprétées comme étant des instructions
destinées à cet effet) et la suppression d'une partie ou de toutes les
représentations de la ressource (par exemple, via un DELETE HTTP, qui dans
certains cas peut avoir comme conséquence la suppression de la ressource
elle-même).
A partir d'un URI donné,
il peut y avoir plusieurs façons d'accéder à une ressource. Le contexte de
l'application détermine la méthode d'accès utilisée par un agent. Par
exemple, un navigateur peut se servir d'un GET HTTP pour obtenir une
représentation d'une ressource, tandis qu'un contrôleur de liens
hypertextes pourrait utiliser un HEAD HTTP pour le même URI, dans le
simple but de déterminer si une représentation est disponible. Certains
schémas d'URI ont des exigences à propos des méthodes d'accès disponibles,
d'autres n'en ont pas (tel que le schéma d'URN [RFC 2141]). La section 1.2.2 du document [URI] aborde, plus en détail, la séparation entre
identification et interaction. Pour plus d'informations sur les relations
entre les méthodes d'accès multiples et la possibilité d'adressage des
URI, reportez-vous aux conclusions du TAG "URI,
la possibilité d'adressage et l'utilisation du GET et du POST HTTP [URIs,
Addressability, and the use of HTTP GET and POST]".
Bien que de nombreux schémas d'URI (§2.4) soient baptisés du nom des
protocoles, l'utilisation d'un URI donné n'implique pas nécessairement
l'accès à la ressource par l'intermédiaire du protocole nommé. Même
lorsqu'un agent emploie un URI pour obtenir une représentation, cet accès
peut se faire par l'intermédiaire de passerelles, de proxies, de zones de
cache et de services de résolution de noms qui sont indépendants du
protocole lié au schéma en question.
Beaucoup de schémas d'URI définissent un protocole par
défaut pour tenter d'accéder à la ressource identifiée. Ce protocole
d'interaction sert souvent de base pour attribuer des identifiants
appartenant au schéma, comme les URI de "HTTP" sont définis en termes de
serveurs HTTP basés sur TCP. Cependant, cela n'implique pas que chaque
interaction avec de telles ressources est limitée au protocole
d'interaction par défaut. Par exemple, les systèmes de récupération
d'informations se servent souvent des proxies pour interagir avec une
multitude de schémas d'URI. En effet, l'utilisation de proxies HTTP permet
d'accéder à des ressources "ftp" et "wais". Ces proxies peuvent également
fournir des services étendus, à l'image des proxies d'annotation. Ceux-ci
combinent l'obtention classique d'information avec une récupération
complémentaire de métadonnées afin de fournir une vue parfaite et
multidimensionnelle des ressources qui utilisent les mêmes protocoles et
les mêmes agents utilisateurs que le web non annoté. De même, de futurs
protocoles pourront être définis et engloberont nos systèmes actuels,
utilisant des mécanismes d'interaction totalement différents, mais sans
pour autant changer les schémas existants des identifiants. Voir également
le principe des spécifications
orthogonales (§5.1).
Déréférencer un URI implique généralement une succession
d'étapes qui sont décrites dans de multiples spécifications et mises en
oeuvre par les agents. L'exemple suivant illustre la série de
spécifications qui régit le processus à suivre lorsqu'un agent utilisateur
doit suivre un lien hypertexte
(§4.4) faisant partie d'un document SVG. Dans cet exemple, l'URI est
"http://weather.example.com/oaxaca" et le contexte d'application demande à
l'agent utilisateur d'obtenir et d'afficher une représentation de la
ressource identifiée.
- L'URI faisant partie d'un lien hypertexte dans un document SVG, la
recommandation SVG 1.1 [SVG11] est
la première spécification appropriée. La section 17.1 de cette spécification importe la sémantique du
lien définie dans XLink 1.0 [XLink10] : "La ressource distante (la destination du
lien) est définie par un URI spécifié par l'attribut XLink
href sur l'élément 'a'". La spécification de
SVG va plus loin en déclarant que l'interprétation d'un élément
a implique d'obtenir une représentation d'une ressource,
identifiée par l'attribut href appartenant à l'espace de
noms XLink : "En activant ces liens (en cliquant avec la souris, par
une saisie clavier, une commande vocale, etc...), les utilisateurs
peuvent visiter ces ressources."
- La spécification XLink 1.0 [XLink10], qui définit l'attribut
href
dans la section 5.4, déclare que "La valeur de l'attribut href doit
être une référence d'URI, comme défini dans le document [IETF RFC
2396], ou encore doit aboutir à une référence d'URI après que la
procédure d'échappement [ndt. escaping procedure] ci-dessous a été
appliqué. La procédure s'applique lors du passage de la référence
d'URI à un résolveur d'URI."
- La spécification d'URI [URI]
annonce que "chaque URI commence par un nom de schéma qui se réfère à
une spécification pour assigner des identifiants suivant ce schéma".
Le nom de schéma d'URI, dans cet exemple, est "http".
- [IANASchemes] spécifie que
le schéma "http" est défini par la spécification HTTP/1.1 (RFC 2616
[RFC2616], section 3.2.2).
- Dans ce contexte SVG, l'agent construit une requête HTTP GET (en
se basant sur la section 9.3 de la [RFC2616]) pour obtenir la représentation.
- La section 6 de la [RFC2616]
définit comment le serveur construit le message de réponse
correspondant, y compris en ce qui concerne le champ
'Content-Type'.
- La section 1.4 de la [RFC2616]
stipule que la "communication HTTP a lieu habituellement au-dessus des
connexions TCP/IP". Cet exemple n'aborde ni cette étape du processus
ni d'autres étapes telles que la résolution du DNS
(Domain Name System).
- L'agent interprète la représentation retournée selon la
spécification en corrélation avec le format de données, correspondant
au type de média
Internet de la représentation (§3.2) (la valeur du champ HTTP
'Content-Type') du registre IANA approprié [MEDIATYPEREG].
Un certain nombre de facteurs,
décrits ci-dessous, influencent qu'elle est (sont) la(les)
représentation(s) obtenue(s) :
- Si le propriétaire de l'URI rend disponibles toutes les
représentations,
- Si l'agent, formulant la requête, possède les privilèges d'accès
pour ces représentations (voir la section sur les liens et contrôle d'accès (§3.5.2)),
- Si le propriétaire de l'URI a fourni plus d'une représentation
(dans différents formats tels que HTML, PNG ou RDF, dans différentes
langues comme l'anglais et l'espagnol, ou si elle est issue d'une
transformation dynamique selon les capacités matérielles ou
logicielles du destinataire), la représentation résultante peut
dépendre d'une négociation entre l'agent utilisateur et le
serveur.
- La période de la demande ; le monde évolue à travers le temps, les
représentations des ressources sont également susceptibles de changer
dans le temps.
En supposant qu'une représentation
a été récupérée avec succès, la puissance expressive du format de la
représentation affectera la précision avec laquelle le fournisseur de
représentation communique l'état de la ressource. Si la représentation
communique l'état de la ressource de façon inexacte, cette inexactitude ou
cette ambiguïté peut mener à une confusion pour les utilisateurs, à propos
de ce qu'est vraiment la ressource. Si les différents utilisateurs
aboutissent à des conclusions différentes à son sujet, ils peuvent alors
l'interpréter comme une collision
d'URI (§2.2.1). Certaines communautés, comme celle qui développe le
web sémantique, cherchent à fournir un framework pour communiquer la
sémantique exacte d'une ressource et ce d'une manière compréhensible par
une machine. La sémantique compréhensible par une machine peut lever une
partie de l'ambiguïté liée à la description des ressources en langage
naturel.
Une représentation est une donnée qui
encode l'information décrivant l'état d'une ressource. Les représentations
ne décrivent pas nécessairement la ressource. Elles ne dépeignent pas
forcement une image de la ressource ou ne représentent pas nécessairement
la ressource dans des sens différents de celui du mot "représente".
Les représentations d'une ressource
peuvent être envoyées ou reçues en utilisant des protocoles d'interaction.
Ces protocoles déterminent à leur tour sous quelle forme les
représentations sont véhiculées sur le Web. HTTP, par exemple, prévoit de
transmettre des représentations comme des flux d'octets, en les typant
avec des types de média Internet [RFC2046].
De la même
manière qu'il est important de réutiliser les schémas d'URI existants
chaque fois que possible, il y a des avantages significatifs à se servir
de flux d'octets typés pour des représentations, même dans le cas peu
courant de la définition d'un nouveau schéma d'URI et du protocole
associé. Par exemple, si le temps d'Oaxaca arrivait au navigateur de Nadia
par le biais d'un protocole différent de HTTP, alors le logiciel
responsable de l'affichage des formats tels que text/xhmtl+xml et
image/png serait toujours utilisable dans la mesure où le nouveau
protocole prendrait en compte la transmission de ces types. C'est un
exemple du principe des spécifications orthogonales (§5.1).
Bonne pratique : Réutiliser les formats de
représentation
Les nouveaux protocoles créés pour le web DEVRAIENT
transmettre les représentations en utilisant des flux d'octets typés avec
les types de média Internet.
Le
mécanisme de type de média Internet a quelques limites. Par exemple, le
type de média, chaîne de caractères, ne supporte ni les paramètres liés à
la gestion des versions (§4.2.1) ni
les autres paramètres. Voir les discussions du TAG à ce sujet : uriMediaType-9 et mediaTypeManagement-45 qui concernent des aspects de ce
mécanisme.
Le type de média Internet définit la syntaxe et la
sémantique de l'identifiant de fragment (introduit dans Identifiants de fragment (§2.6)). Il peut, le cas
échéant, être utilisé en conjonction d'une représentation.
Scénario
Dans une de ses pages XHTML, Dirk crée un lien hypertexte
vers une image que Nadia a publiée sur le Web. Il le crée en écrivant
<a href="http://www.example.com/images/nadia#hat">La chapeau
de Nadia</a>. Emma regarde la page XHTML de Dirk dans son
navigateur web et suit le lien. La mise en oeuvre HTML de son navigateur
supprime le fragment de l'URI puis demande l'image
"http://www.example.com/images/nadia". Nadia fournit une représentation
SVG de l'image (avec le type de média Internet "image/svg+xml"). Le
navigateur Web d'Emma démarre alors la mise en oeuvre SVG afin de voir
l'image. Il lui passe l'URI original, comprenant le fragment,
"http://www.example.com/images/nadia#hat", permettant ainsi de ne voir que
le chapeau et non l'image complète.
Notez que la mise en oeuvre HTML du navigateur d'Emma n'a
pas eu besoin de comprendre la syntaxe ou la sémantique du fragment SVG
(et inversement, l'outil SVG n'a pas besoin de comprendre la syntaxe de
fragment ou la sémantique HTML, WebCGM, RDF... ; il lui suffit de
reconnaître le délimiteur # de la syntaxe d'URI [ URI ] et d'enlever le
fragment pour accéder à la ressource). Cette orthogonalité (§5.1) est un fonctionnalité importante de
l'architecture du Web. En effet, c'est ce qui permet au navigateur d'Emma
de fournir un service utile sans pour autant exiger une mise à jour.
La sémantique d'un identifiant de fragment
est définie par l'ensemble des représentations qui pourraient résulter
d'une action de récupération de la ressource primaire. Le format et la
résolution du fragment dépendent donc du type de la représentation
potentiellement obtenue, même si une telle récupération n'est seulement
effectuée que si l'URI est déréférencé. Si aucune représentation n'existe,
alors la sémantique du fragment est considérée comme inconnue et, de fait,
sans contrainte. La sémantique de l'identifiant de fragment est
orthogonale au schéma d'URI et ne peut pas être redéfinie ainsi par une
spécification de schéma d'URI.
L'interprétation de l'identifiant de fragment est
seulement effectuée par l'agent qui déréférence un URI ; l'identifiant de
fragment n'est pas passé à d'autres systèmes pendant le processus de
récupération. Cela signifie que certains intermédiaires dans
l'architecture du web (comme les proxies) n'ont aucune interaction avec
les identifiants de fragment et que les redirections (dans HTTP [RFC2616] par exemple) ne s'appliquent pas
aux fragments.
La négociation de contenu
consiste à fournir de multiples représentations par l'intermédiaire d'un
même URI. La négociation, entre l'agent émetteur de la requête et le
serveur, détermine quelle représentation est servie (habituellement avec
pour objectif de servir la "meilleure" représentation pouvant être traitée
par un agent la recevant). HTTP est un exemple de protocole qui permet à
des fournisseurs de représentation d'utiliser la négociation de
contenu.
Les différents formats de
données peuvent définir leurs propres règles pour l'usage de la syntaxe de
l'identifiant de fragment afin de spécifier différents types de
sous-ensembles, de vues ou de références externes qui sont identifiables,
par ce type de média, en tant que ressources secondaires. Par conséquent,
les fournisseurs de représentations doivent contrôler soigneusement la
négociation de contenu lorsqu'elle est utilisée avec un URI qui contient
un identifiant de fragment. Considérons un exemple dans lequel le
propriétaire de l'URI "http://weather.example.com/oaxaca/map#zicatela"
emploie la négociation de contenu pour délivrer deux représentations de la
ressource identifiée. Trois cas sont possibles :
- L'interprétation de "zicatela" est définie de façon consistante
par les spécifications des deux formats de données. Le fournisseur de
la représentation décide quand les définitions de la sémantique de
l'identifiant de fragment sont suffisamment cohérentes.
- L'interprétation de "zicatela" est définie de façon inconsistante
par les spécifications des formats de données.
- L'interprétation de "zicatela" est définie dans une spécification
de format de données mais pas dans l'autre.
La première situation (où la
sémantique est consistante) ne pose aucun problème.
Le deuxième cas est une erreur de gestion du serveur : les
fournisseurs de représentations ne doivent pas utiliser la négociation de
contenu pour servir des formats de représentation dont la sémantique de
l'identifiant de fragment est inconsistant. Cette situation conduit
également à une collision d'URI
(§2.2.1).
Le troisième cas n'est
pas une erreur de gestion du serveur. C'est un moyen pour le Web de se
développer. Puisque le Web est un système réparti dans lequel des formats
et des agents sont déployés d'une façon non-uniforme, l'architecture du
web ne contraint pas les auteurs à utiliser que des formats "ayant le plus
petit dénominateur commun". Les auteurs de contenu peuvent tirer profit de
nouveaux formats de données tout en s'assurant toujours d'une
compatibilité ascendante raisonnable pour les agents qui ne les mettent
pas encore en oeuvre.
Dans le
troisième cas, le comportement de l'agent réceptionnant peut changer en
fonction de la définition éventuelle, par le format négocié, de la
sémantique de l'identifiant de fragment. Quand un format de données reçu
ne définit pas cette sémantique, l'agent ne devrait pas passer sous silence la reprise sur erreur
à moins que l'utilisateur ait donné son consentement ; voir [CUAP] pour la suggestion de comportements
complémentaires de l'agent dans ce cas précis.
Voir les discussions associées du TAG, RDFinXHTML-35.
Une communication
réussie entre deux parties dépend d'une compréhension raisonnablement
partagée de la sémantique des messages échangés, non seulement au niveau
des données mais également au niveau des métadonnées. Parfois, il peut y
avoir des contradictions entre les données et les métadonnées d'un
expéditeur de message. Voici des exemples, observés dans la pratique, de
ce type d'inconsistance sont :
- L'encodage réel des caractères d'une représentation (par exemple,
"iso-8859-1", spécifié par l'attribut
encoding dans une
déclaration XML) est contradictoire avec le paramètre du jeu de
caractères présent dans les métadonnées de la représentation (par
exemple, "utf-8", indiqué par le champ "Content-Type" dans un en-tête
HTTP).
- L'espace de noms
(§4.5.3) de l'élément racine des données XML d'une représentation
(par exemple, celui spécifié par l'attribut "xmlns") est
contradictoire avec la valeur du champ "Content-Type" dans un en-tête
HTTP.
D'un autre côté, il n'y a aucune
contradiction à servir un contenu HTML en ayant un type de média
"text/plain", par exemple, car cette combinaison est autorisée par les
spécifications.
Les agents récepteurs
devraient détecter les inconsistances liées au protocole et gérer une reprise sur erreur
appropriée.
Contrainte: Inconsistance des
données/métadonnées
Les agents NE DOIVENT PAS ignorer les métadonnées des
messages sans le consentement de l'utilisateur.
Ainsi, par exemple, si les responsables du site
"weather.example.com" marquent de manière erronée la photo satellite
d'Oaxaca avec le type "image/gif" au lieu de "image/jpeg" et si le
navigateur de Nadia détecte un problème, il ne doit pas l'ignorer (en
affichant simplement l'image JPEG par exemple) sans le consentement de
Nadia. Le navigateur de Nadia peut l'informer du problème ou peut non
seulement l'en informer mais aussi prendre une mesure corrective.
En outre, les fournisseurs de
représentation peuvent aider à réduire le risque d'inconsistance en
attribuant soigneusement les métadonnées de la représentation (en
particulier celles qui s'appliquent à plusieurs représentations). La
section sur les types de média
pour XML (§4.5.7) présente un exemple permettant de réduire le risque
d'erreur, en ne fournissant aucune métadonnée concernant l'encodage de
caractères lorsqu'il s'agit de délivrer du XML.
L'exactitude des métadonnées repose sur les
administrateurs du serveur, les auteurs des représentations et le logiciel
qu'ils utilisent. En pratique, les possibilités des outils et les
relations sociales peuvent être des facteurs limitants.
L'exactitude de ces dernières et des autres
champs de métadonnées est aussi importante pour les ressources dynamiques
du Web, où un peu de réflexion et de programmation peuvent souvent assurer
des métadonnées correctes pour un grand nombre de ressources.
Il y a souvent une séparation de contrôle entre
les utilisateurs qui créent des représentations de ressources et les
gestionnaires de serveur qui maintiennent le logiciel du site Web. Ceci
étant dit, le logiciel du site web est généralement à l'origine des
métadonnées qui sont associées à une ressource. Il en résulte qu'une
coordination entre les gestionnaires de serveur et les créateurs de
contenu est nécessaire.
Bonne pratique : Association de métadonnées
Les gestionnaires de
serveur DEVRAIENT permettre aux créateurs de représentation de contrôler
les métadonnées liées à leurs représentations.
En particulier, les créateurs de contenu doivent pouvoir
définir le type de contenu (pour l'extensibilité) et l'encodage des
caractères (pour une internationalisation appropriée).
Les conclusions du TAG, "métadonnées qui font autorité [Authoritative
Metadata]", abordent plus en détail la façon de traiter la
consistance données/métadonnées et la façon dont la configuration d'un
serveur peut être employée pour l'éviter.
L'obtention par Nadia d'informations sur le temps (un
exemple de requête en lecture seule ou d'une recherche) est qualifiée d'interaction
sûre. Une interaction sûre implique que l'agent ne provoque
aucune obligation en dehors de l'interaction. Un agent peut provoquer des
obligations par d'autres moyens (comme par la signature d'un contrat). Si
un agent n'a pas d'engagement avant une interaction sûre, il ne doit pas
en avoir après.
D'autres interactions
web ressemblent plus à des ordres qu'à des questions. Ces interactions non sûres
peuvent induire un changement d'état d'une ressource et l'utilisateur peut
être jugé responsable des conséquences de ces interactions. Les
interactions non sûres incluent la souscription à une lettre d'actualité,
l'envoi de message à une liste ou la modification d'une base de données.
Note : Dans ce contexte, le mot "non sûr" ne signifie pas
nécessairement "dangereux". Le terme "sûr" est employé dans la section
9.1.1 de la [RFC2616] et le terme "non
sûr" constitue son opposé naturel.
Scénario
Nadia décide de réserver
des vacances à Oaxaca via "booking.example.com". Elle saisit des données
dans une série de formulaires en ligne et finalement les informations
relatives à sa carte de crédit lui sont demandées, pour pouvoir acheter
les billets d'avion. Elle les fournit dans un autre formulaire. Quand elle
appuie sur le bouton "acheter", son navigateur ouvre une autre connexion
réseau au serveur "booking.example.com" et envoie, en utilisant la méthode
POST, un message avec des données issues du formulaire. C'est une interaction non sûre.
Nadia souhaite changer l'état du système en échangeant de l'argent contre
des billets d'avion.
Le serveur lit la
requête POST et, après l'exécution de la transaction de réservation,
renvoie un message au navigateur de Nadia qui contient une représentation
des résultats de sa demande. Les données de la représentation sont en
XHTML de sorte que Nadia puisse les sauver ou les imprimer.
Notez que ni les données transmises par POST, ni
les données reçues dans la réponse ne correspondent nécessairement à une
ressource identifiée par un URI.
Les interactions sûres sont importantes parce que ce sont
des interactions parmi lesquelles les utilisateurs peuvent naviguer en
toute confiance et où les agents (en incluant les moteurs de recherche et
les navigateurs qui mettent en cache des données pour l'utilisateur)
peuvent suivre des liens hypertextes sans risque. Les utilisateurs (ou les
agents agissant en leur nom) ne s'engagent à rien en demandant une
ressource ou en suivant un lien hypertexte.
Principe: Récupération
sûre
Les
agents ne s'engagent pas en récupérant une représentation.
Par exemple, il est incorrect de publier
un URI qui contient des informations (une partie de l'URI) permettant
d'inscrire un utilisateur à une liste de discussions. Rappelez-vous que
les moteurs de recherche peuvent suivre de tels liens hypertextes.
Le fait qu'un GET HTTP, la méthode d'accès
la plus souvent utilisée pour suivre un lien hypertexte, soit sûre
n'implique pas que toutes les interactions sûres doivent être faites via
des GET HTTP. Parfois, il peut y avoir de bonnes raisons (comme pour des
besoins de confidentialité ou des limites pratiques quant à la longueur
des URI) de mener une opération sûre, par un autre moyen, en utilisant un
mécanisme généralement réservé aux opérations non sûres (par exemple, un
POST HTTP).
Pour plus d'informations
sur les opérations sûres et non sûres employant les méthodes GET et POST
de HTTP ainsi que sur les aspects de traitement de la sécurité liés à
l'utilisation du GET HTTP, reportez-vous aux conclusions du TAG :
"URI, possibilité d'adressage et utilisation des commandes
HTTP GET et POST [URIs, Addressability, and the use of HTTP GET and
POST]".
Scénario
Nadia paie ses billets d'avion en ligne (par une
interaction POST comme décrit ci-dessus). Elle reçoit une page web avec
l'information de confirmation et souhaite la mettre dans ses favoris de
sorte qu'elle puisse s'y référer quand elle calculera ses dépenses. Bien
que Nadia puisse imprimer ces résultats ou encore les sauvegarder dans un
fichier, elle voudrait également pouvoir les conserver en tant que
favori.
Les requêtes et
les résultats de transaction sont des ressources à valeur ajoutée et comme
toutes les ressources de ce type, il est utile de pouvoir s'y rapporter à
l'aide d'un URI persistant
(§3.5.1). Cependant, dans la pratique, Nadia ne peut pas conserver sa
confirmation de paiement (exprimée par l'intermédiaire d'une requête POST)
ni la confirmation de la compagnie aérienne ni même l'engagement qu'une
place lui est réservée (exprimé par l'intermédiaire de la réponse au
POST).
Il existe des solutions pour
fournir des URI persistants pour des requêtes de transaction et pour leurs
résultats. Pour les requêtes, les agents utilisateur peuvent fournir une
interface de gestion des transactions où l'agent utilisateur s'est engagé
au nom de l'utilisateur. Pour les résultats de transaction, HTTP permet
aux fournisseurs de représentation d'associer un URI aux résultats d'une
requête POST HTTP en utilisant l'en-tête de "Content-Location" (décrit
dans section 14.14 de la [RFC2616]).
Scénario
Comme Nadia trouve le site
indiquant le temps d'Oaxaca utile, elle envoie son point de vue, par
courrier électronique, à son ami Dirk en lui recommandant de regarder
'http://weather.example.com/oaxaca'. Dirk clique sur le lien hypertexte
apparaissant dans le courriel qu'il reçoit mais une erreur 404 (non
trouvé) le frustre. Dirk essaie de nouveau le jour suivant et reçoit une
représentation avec des "nouvelles" vieilles de deux semaines. Il essaie
une fois de plus le jour suivant et obtient une représentation clamant que
le temps à Oaxaca est ensoleillé, alors que ses amis y habitant lui disent
par téléphone, qu'en fait, il pleut. Dirk et Nadia concluent que les
propriétaires de l'URI ne sont pas fiables ou sont imprévisibles. Bien que
le propriétaire de cet URI ait choisi le web comme moyen de communication,
il vient de perdre deux clients à cause d'une gestion inefficace de ses
représentations.
Un
propriétaire d'URI peut fournir plusieurs représentations officielles de
la ressource identifiée par cet URI, ou bien aucune. Fournir des
représentations bénéficie cependant à la communauté.
Bonne pratique : Disponibilité des
représentations
Un propriétaire d'URI DEVRAIT fournir des représentations
de la ressource qu'il identifie.
Par exemple, les propriétaires des URI d'espace de noms
XML devraient les utiliser pour identifier un document d'espace de noms
(§4.5.4).
La disponilité de
représentations ne signifie pas qu'il est toujours souhaitable de les
récupérer. En fait, dans certains cas, c'est l'inverse.
Principe: La référence n'implique pas la
déréférence
Un développeur d'application ou un auteur de
spécifications NE DEVRAIT PAS avoir besoin de récupérer les
représentations à travers le réseau chaque fois qu'elles sont
référencées.
Déréférencer un
URI induit un coût (potentiellement significatif) au niveau des ressources
informatiques et de la bande passante. Cela peut avoir des implications du
point de vue de la sécurité et peut imposer une latence significative à
l'application qui déréférence. Les URI déréférencés devraient être évités
sauf lorsqu'ils sont nécessaires.
Les
sections suivantes abordent quelques aspects de la gestion des
représentations, comme la promotion de la persistance d'URI (§3.5.1), la gestion de l'accès aux ressources (§3.5.2) et le support de la navigation
(§3.5.3).
Comme c'est le cas pour beaucoup d'interactions
humaines, la confiance dans les interactions via le web dépend de la
stabilité et de la prévisibilité. Pour une ressource d'information, la
persistance dépend de la consistance des représentations. Le fournisseur
de représentations décide lorsqu'elles sont suffisamment consistantes
(même si cette détermination tient compte généralement des attentes des
utilisateurs).
Bien que l'on puisse
dans ce cas observer la persistance comme le résultat de l'obtention d'une
représentation, le terme persistance d'URI est utilisé
pour décrire une propriété vraiment souhaitable : un URI, une fois associé
à une ressource, devrait continuer indéfiniment à se référer à cette
ressource.
Bonne pratique : Représentation
consistante
Un propriétaire d'URI DEVRAIT fournir des représentations
consistantes et prédictibles de la ressource identifiée.
La persistance d'URI est une question de
politique et d'engagement de la part du propriétaire d'URI. Le choix d'un schéma particulier
d'URI ne garantit pas que ces URI seront persistants ou qu'ils ne le
seront pas.
HTTP [RFC2616] a été conçu pour aider au contrôle de la
persistance d'URI. Par exemple, la redirection HTTP (utilisant les codes
de réponse 3xx) permet à des serveurs d'indiquer à un agent qu'il doit
prendre d'autres mesures pour finaliser la requête (par exemple, un nouvel
URI est associé à la ressource).
En
outre, la négociation de contenu
favorise également la consistance, car un gestionnaire de site n'est pas
dans l'obligation de définir de nouveaux URI lorsqu'il ajoute le support
d'une nouvelle spécification de format. Les protocoles, qui ne prennent
pas en compte la négociation de contenu (tel que FTP), exigent un nouvel
identifiant lors de l'introduction d'un nouveau format de données. La
mauvaise utilisation de la négociation de contenu peut aboutir à des
représentations inconsistantes.
Le
document [Cool] présente davantage
d'échanges au sujet de la persistance d'URI.
Il est raisonnable de limiter l'accès à une ressource
(pour des raisons commerciales ou de sécurité, par exemple). Mais,
l'identification d'une ressource se rapproche simplement de celle d'un
livre par son titre. Dans des circonstances exceptionnelles, les personnes
peuvent s'entendre pour maintenir des titres ou des URI confidentiels
(par exemple, un auteur de livre et un éditeur peuvent se mettre d'accord
pour garder secret l'URI de la page, contenant des informations
complémentaires, jusqu'à l'édition du livre). Dans le cas contraire, ces
titres et ces URI sont librement échangeables.
Voici une analogie : Les propriétaires d'un bâtiment
pourraient avoir une politique stipulant que le public ne peut entrer dans
le bâtiment que par l'intermédiaire de la porte principale et seulement
pendant les heures de bureau. Ceux qui travaillent dans le bâtiment et qui
effectuent des livraisons pourraient se servir d'autres portes plus
appropriées. Une telle politique serait renforcée par une sécurité
effectuée par le personnel ainsi que par des dispositifs mécaniques tels
que des serrures et des passages contrôlés par des cartes d'accès. Mettre
en place cette politique ne requiert pas de cacher certaines entrées du
bâtiment, ni de demander à la législation l'utilisation obligatoire de la
porte principale et d'interdire toute autre porte d'accès au bâtiment.
Scénario
Nadia envoie à Dirk l'URI de l'article qu'elle est en
train de lire. Avec son navigateur, Dirk suit le lien hypertexte et est
invité à s'identifier en saisissant son nom d'utilisateur et son mot de
passe. Dirk étant également un abonné des services fournis par
"weather.example.com", il peut accéder aux mêmes informations que Nadia.
Ainsi, l'autorité contrôlant "weather.example.com" peut limiter l'accès
aux personnes autorisées et continuer à fournir les avantages des URI.
Le web fournit plusieurs
mécanismes pour contrôler l'accès aux ressources ; ces mécanismes ne se
basent pas sur le masquage ou la suppression des URI de ces ressources.
Pour plus d'informations, voir les conclusions du TAG "Lien
en profondeur dans le World Wide Web ["Deep Linking" in the World Wide
Web]".
La possibilité de faire et de partager des liens est une
force de l'architecture du Web. Un utilisateur, qui a trouvé une partie
intéressante du Web, peut partager cette expérience simplement en
republiant un URI.
Scénario
Nadia et Dirk veulent
visiter le musée des prévisions météorologiques dans Oaxaca. Nadia se rend
sur "http://maps.example.com", localise le musée et expédie par courriel
l'URI "http://maps.example.com/oaxaca?lat=17.065;lon=-96.716;scale=6" à
Dirk. Dirk se rend sur "http://mymaps.example.com", localise le musée et
envoie, par courriel également, l'URI
"http://mymaps.example.com/geo?sessionID=765345;userID=Dirk"
