RFC 8288 : Le Web Linking

Un lien n'est pas un objet HTML. C'est une relation abstraite entre deux ressources. La balise <a> n'est qu'une façon parmi d'autres de représenter cette relation.

La RFC 8288 définit précisément ce modèle de relations et, surtout, comment les transporter dans la couche HTTP sans passer par le contenu de la page.

Le modèle : Source, Cible et Type

Un lien est composé d'un contexte (la source), d'une cible (la destination) et d'un type de relation qui les unit.

Pour que cette relation soit exploitable par les machines, la RFC s'appuie sur l'IRI (Internationalized Resource Identifier), une extension de l'URI qui supporte les caractères non-ASCII.

  • Le Link Context : L'IRI de la ressource source. Par défaut, c'est la ressource courante, mais le paramètre anchor permet de désigner une autre source.
  • Le Link Target : L'IRI vers laquelle on pointe. Elle peut être relative ou absolue.
  • La Link Relation Type : Un token (rel) qui qualifie la relation. Les types standards sont enregistrés auprès de l'IANA (canonical, alternate, preload...).

Sans ce typage explicite, un lien reste une simple référence sans sémantique exploitable. C'est cette structure formelle qui permet aux clients HTTP de distinguer une relation de navigation d'une dépendance critique comme une feuille de style.

La sérialisation dans le Header HTTP

C'est là que ça devient utile : on peut déclarer un lien dans l'en-tête de la réponse du serveur.

L'avantage ? On peut lier des ressources qui n'ont pas de corps HTML (PDF, images, polices). Un serveur peut répondre avec un fichier tout en indiquant ses métadonnées via le header :

Link: <https://api.monsite.com/docs/policy.pdf>; rel="canonical"; type="application/pdf"

Cette méthode permet au client (navigateur, crawler) d'identifier les relations entre ressources dès la réception des en-têtes HTTP, avant même d'analyser le contenu. Elle s'inscrit dans le modèle REST en séparant métadonnées et représentation, et permet notamment d'optimiser le chargement via des relations explicites comme rel="preload" ou rel="preconnect".

Pourquoi s'en soucier ?

Sortir du "tout HTML" permet de gérer des problématiques structurelles :

  • Performance : Indiquer des ressources à précharger (rel="preload") via le header pour que le navigateur anticipe le téléchargement.
  • Découvrabilité : Lier des APIs entre elles (HATEOAS) sans polluer le corps de la réponse.
  • Sémantique : Définir des relations sur des fichiers binaires qui n'acceptent pas de code.

📘 Le HTML est une vue du lien. Le Header HTTP est sa déclaration structurelle.

À retenir

RFC 8288 permet de déclarer des relations entre ressources au niveau HTTP, sans dépendre du format du contenu. Concrètement : un PDF peut indiquer son auteur, une image peut pointer vers sa version haute résolution, une API peut exposer sa pagination directement dans les headers.

L'intérêt est double : le client peut exploiter ces métadonnées avant même de parser le corps de la réponse (gain de performance), et les ressources non-HTML deviennent aussi expressives que les pages web classiques.

← TOUS LES DOSSIERS