Aller au contenu principal

2. Links (Liens)

Dans cette spécification, un lien est une connexion typée entre deux ressources, composée des éléments suivants :

  • un contexte de lien (link context)
  • un type de relation de lien (link relation type) (section 2.1)
  • une cible de lien (link target)
  • des attributs de cible optionnels (target attributes) (section 2.2)

Un lien peut être considéré comme l'affirmation suivante : « le contexte de lien possède une ressource de type relation de lien à la cible de lien, laquelle possède les attributs de cible ».

Par exemple, « https://www.example.com/ » possède une ressource « canonical » à « https://example.com », laquelle a un « type » de « text/html ».

Le contexte de lien et la cible de lien sont tous deux des IRI (Internationalized Resource Identifiers, identifiants de ressources internationalisés) [RFC3987]. Cependant, dans le cas courant, le contexte de lien sera également un URI [RFC3986], car de nombreux protocoles (comme HTTP) ne prennent pas en charge le déréférencement des IRI. De même, la cible de lien est parfois convertie en URI dans les sérialisations qui ne prennent pas en charge les IRI (par exemple, le champ d'en-tête Link défini à la section 3) (voir la section 3.1 de [RFC3987]).

Cette spécification n'impose aucune restriction sur la cardinalité des liens ; il peut y avoir plusieurs liens vers une cible particulière et depuis une cible particulière, ainsi que plusieurs liens du même type ou de types différents entre un contexte et une cible donnés. De même, l'ordre relatif des liens dans une sérialisation particulière ou entre sérialisations (par exemple, entre le champ d'en-tête Link et les liens dans le contenu) n'est pas spécifié ni significatif dans cette spécification ; les applications souhaitant considérer l'ordre comme significatif peuvent le faire.

Les liens sont véhiculés dans des sérialisations de liens ; ce sont des « octets sur le fil » qui peuvent prendre diverses formes. Par exemple, Atom [RFC4287] et HTML [W3C.REC-html5-20141028] définissent tous deux des façons de sérialiser des liens dans leurs formats respectifs, et la section 3 définit comment sérialiser des liens dans des champs d'en-tête HTTP.

Cette spécification ne définit pas de syntaxe commune pour les liens à travers différentes sérialisations, et n'impose pas de contexte particulier pour un lien donné ; on s'attend à ce que la sérialisation du lien spécifie ces deux aspects.

Enfin, les liens sont utilisés par des applications de liens. En général, une application définira les types de relation de lien qu'elle utilise, ainsi que les sérialisations dans lesquelles ils peuvent apparaître. Par exemple, l'application « navigation Web » recherche le type de relation de lien « stylesheet » dans la sérialisation de liens HTML (et optionnellement dans le champ d'en-tête Link), tandis que l'application « AtomPub » utilise les relations de lien « edit » et « edit-media » dans la sérialisation Atom.

Dans le cas le plus simple, un type de relation de lien identifie la sémantique du lien. Par exemple, un lien avec le type de relation « copyright » indique que le contexte de lien actuel possède une ressource de copyright à la cible du lien.

Les types de relation de lien peuvent également être utilisés pour indiquer que la ressource cible possède des attributs particuliers ou présente un comportement particulier ; par exemple, un lien « service » implique que la cible du lien peut être utilisée comme partie d'un protocole défini (dans ce cas, une description de service).

Les types de relation ne doivent pas être confondus avec les types de médias [RFC2046] ; ils n'identifient pas le format de la représentation obtenue lors du déréférencement du lien. Ils décrivent uniquement comment le contexte actuel est lié à une autre ressource.

Les types de relation NE DEVRAIENT PAS (SHOULD NOT) inférer de sémantique supplémentaire basée sur la présence ou l'absence d'un autre type de relation de lien ou sur la cardinalité de ses propres occurrences. Une exception est la combinaison des types de relation enregistrés « alternate » et « stylesheet », qui a une signification particulière en HTML pour des raisons historiques.

Il existe deux types de relations : enregistrées et étendues.

2.1.1. Registered Relation Types (Types de relation enregistrés)​

Les types de relation bien définis peuvent être enregistrés comme jetons pour faciliter et/ou encourager leur réutilisation par d'autres applications, en utilisant la procédure de la section 2.1.1.1.

Les noms de types de relation enregistrés DOIVENT (MUST) être conformes à la règle reg-rel-type (voir section 3.3), et DOIVENT (MUST) être comparés caractère par caractère de manière insensible à la casse. Ils DEVRAIENT (SHOULD) être appropriés à la spécificité du type de relation ; c'est-à-dire que si la sémantique est très spécifique à une application particulière, le nom devrait le refléter, afin que des noms plus génériques soient disponibles pour des usages moins spécifiques.

Les types de relation enregistrés NE DOIVENT PAS (MUST NOT) contraindre le type de médias du contexte de lien, et NE DOIVENT PAS (MUST NOT) contraindre les types de médias de représentation disponibles pour la cible du lien. Cependant, ils peuvent spécifier le comportement et les attributs de la ressource cible (par exemple, les méthodes HTTP autorisées, ainsi que les types de médias de requête et de réponse devant être pris en charge).

2.1.2. Extension Relation Types (Types de relation étendus)​

Les applications qui ne souhaitent pas enregistrer un type de relation peuvent utiliser des types de relation étendus, qui sont des URI [RFC3986] identifiant de manière unique le type de relation. Bien que l'URI puisse pointer vers une ressource contenant une définition de la sémantique du type de relation, les clients NE DEVRAIENT PAS (SHOULD NOT) accéder automatiquement à cette ressource pour éviter de surcharger ses serveurs.

L'URI utilisé pour un type de relation étendu DEVRAIT (SHOULD) être sous le contrôle de la personne ou de l'entité qui le définit, ou lui être délégué.

Lors de la comparaison de types de relation étendus, ils DOIVENT (MUST) être comparés caractère par caractère de manière insensible à la casse (après conversion en URI si sérialisés dans un format différent). Par conséquent, les URI entièrement en minuscules DEVRAIENT (SHOULD) être utilisés pour les relations étendues.

Notez que bien que les types de relation étendus doivent être des URI, la sérialisation d'un lien peut spécifier qu'ils sont représentés sous une autre forme, à condition qu'ils puissent être convertis en URI.

2.2. Target Attributes (Attributs de cible)​

Les attributs de cible sont une liste de paires clé/valeur décrivant le lien ou sa cible ; par exemple, des indications sur le type de médias.

Ils peuvent être définis par des types de relation de lien individuels et des sérialisations de liens.

Cette spécification ne tente pas de coordonner les noms des attributs de cible, leur cardinalité ou leur utilisation. Les personnes créant et maintenant des sérialisations DEVRAIENT (SHOULD) coordonner leurs attributs de cible pour éviter les conflits sémantiques ou syntaxiques, et PEUVENT (MAY) définir leurs propres registres d'attributs de cible.

Les noms des attributs de cible DEVRAIENT (SHOULD) être conformes à la règle token, mais NE DEVRAIENT PAS (SHOULD NOT) être limités à l'ASCII ; ils DEVRAIENT (SHOULD) être comparés de manière insensible à la casse.

Dernière mise à jour le