Ce qui suit est une traduction libre de l'article How to make a good ID in Atom de Mark Pilgrim, le vendredi 28 mai 2004.
Je me suis permis de le compléter avec le flux RSS et mettre à jour une RFC.

Table des matières :

Avant-propos

Lorsque l'article fera référence à l'élément <id>, il s'agira soit de l'élément <id> du flux Atom, soit de l'élément <guid> du flux RSS. Et ce, par soucis de lisibilité. Cependant, tout ce qui suit est valable pour les flux Atom comme RSS.

Introduction

Chaque entrée d'un flux Atom/RSS doit avoir un ID globalement unique, dans l'élément <id>. Cela aide les agrégateurs à garder une trace de l'entrée, même si elle est mise à jour. Certains agrégateurs réaffichent les entrées modifiées, d'autres non, d'autres changent au fil du temps. Mais avant de pouvoir faire quoi que ce soit, vous devez identifier chaque entrée de manière unique, et c'est le rôle de <id>.

Il y a 3 conditions requises pour un ID :

  1. L'ID doit être un URI valide, tel que défini par la RFC 2396 RFC 3986.
  2. L'ID doit être globalement unique, quelque soit le flux Atom/RSS, partout, et pour toujours. Il s'avère que cette partie est plus facile qu'elle n'y paraît.
  3. L'ID ne doit jamais, jamais changer.

Il existe plusieurs manières de construire un ID immuable globalement unique, mais certaines sont mieux que d'autres.

Pourquoi vous ne devriez pas utiliser le permalien comme ID

Le fait d'utiliser l'URL du permalien comme <id> est valide, mais je le déconseille parce qu'il peut porter à confusion sur l'élément qui devrait être traité comme permalien. Les développeurs qui ne lisent pas les spécifications regarderont votre flux Atom/RSS et verront deux éléments d'information identiques, ils en choisiront un comme permalien, et certains se tromperont. Puis il iront vers un autre flux où les deux éléments ne sont pas les mêmes, et seront confus.

Dans un flux Atom/RSS, <link rel="alternate"> est toujours le permalien de l'entrée. <id> est toujours l'unique identifiant de l'entrée. Les deux sont requis, mais ils ont des objectifs différents. L'ID d'une entrée ne devrait jamais changer, même si le permalien est modifié.

« Permalien modifié » ? Oui, les permaliens ne sont pas aussi permanents qu vous pourriez le penser. Voici un exemple qui m'est arrivé. Mes permaliens étaient générés automatiquement d'après le titre de mon entrée, mais plus tard j'ai mis à jour une entrée et modifé le titre. Devinez quoi, l'URL du "permalien" avait changé ! Si vous êtes malins, vous pouvez utiliser une redirection HTTP pour rediriger le visiteur depuis un ancien permalien vers le nouveau (ce que j'ai fait). Mais vous ne pouvez pas rediriger un ID.

L'ID d'une entrée Atom/RSS ne doit jamais changer ! Dans l'idéal, vous devriez générer l'ID d'une entrée une seule fois, et le stocker quelque part. Si vous le générez automatiquement, à chaque fois que vous apporterez un changement, l'ID de l'entrée sera modifié, ce qui va à l'encontre de l'objectif.

Pourquoi vous ne devriez pas utiliser un URN comme ID

La RFC 2141 définie la syntaxe pour les URN. Les URN ont été spécialement élaboré pour être utilisés comme identifiant globalement unique. Il s'agit d'URI valides. Ils ressemblent, en quelque sorte, aux URL que vous tapez dans la barre d'adresse d'un naviagteur, à ceci près que les URN ne sont pas déstinés à être cliquable. Ce sont de simples identificateurs structurés.

Alors pourquoi ne pas les utiliser ? Eh bien, la raison principale est qu'ils doivent être enregistrés (comme décrit dans la RFC 3406). Vous ne pouvez pas juste utiliser le nom de domaine que vous avez déjà ; l'enregistrement d'un espace de nom URN est un processus à part.

Si vous avez enregistré un espace de nom URN, alors vous pouvez l'utiliser pour générer des ID. Dans le cas contraire, vous ne pouvez pas simplement utiliser un URN et le publier. Les URN ne fonctionnent pas de cette manière.

Comment générer un ID à l'aide du Tag URI

Il y a un standard émergeant qui permet à tout le monde de générer des identifiants globaux uniques sans enregistrement : le Tag URI. Pour en générer un, seuls un nom de domaine et une adresse courriel sont nécessaires. (Un sous-domaine fonctionne aussi.) Pour ce tutoriel, je supposerai que vous possédez votre propre nom de domaine ou sous-domaine, et que vous ne souhaitiez pas divulguer votre adresse courriel aux yeux des spammeurs.

Commençons par l'URL du permalien. J'utiliserait http://diveintomark.org/archives/2004/05/27/howto-atom-linkblog, un exemple d'article réel. Votre permalien peut sembler différent, il ne contient peut-être pas de date, ou est composé d'un simple ID numérique ; il peut contenir un identifiant fragmenté (avec la marque #). Pas de soucis, vous pouvez construire un Tag URI à partir de n'importe quelle URL.

  1. Jeter tout ce qui précède le nom de domaine :
    diveintomark.org/archives/2004/05/27/howto-atom-linkblog
  2. Remplacer tous les # par / :
    (dans notre cas, rien ne change)
  3. Juste après le nom de domaine, ajoutez une virgule, suivie de l'année-mois-jour de publication de l'article, puis deux-points (« : »). Veillez à noter l'année sur 4 chiffres, le mois et le jour sur deux chiffres chacun. N'oubliez pas le deux-points :
    diveintomark.org,2004-05-27:/archives/2004/05/27/howto-atom-linkblog
  4. Ajoutez tag: au début. (N'ajoutez pas de barres obliques, ou slashes, c'est juste “tag:“. C'est une erreur commune.) :
    tag:diveintomark.org,2004-05-27:/archives/2004/05/27/howto-atom-linkblog

Voilà ! Il y a d'autres manières de créer un Tag URI valide, mais cette procédure fonctionne pour toutes les URL.

Le seul problème potentiel que je vois, c'est si votre permalien est amené à changer dans le temps (par exemple, s'il est basé sur le titre et que vous le modifier après publication, ou si vous changer radicalement le schéma URL des permaliens), vous ne devez pas reconstruire le Tag URI à chaque fois que le permalien change. Dans l'idéal, vous devriez générer une seule fois l'ID et le stocker avec le reste des données de l'entrée. Si ça n'est pas faisable, et si vous ne pouvez pas garantir que vos permaliens ne changeront jamais, vous devriez envisager une autre méthode pour générer le Tag URI.

Autres méthodes pour construire un ID valide

  • Par une quelconque clef interne, telle que la clef primaire de votre entrée dans la table de la base de données. Par exemple, dans Movable Type, l'étiquette modèle <$MTEntryID$> vous donnera la clef primaire de la table mt_entry. Pour une entrée donnée, cette clef ne changera jamais. Ça n'est pas un Tag URI valide à proprement parlé (c'est juste un nombre), mais il peut servir à générer un Tag URI valide. Exemple :
    tag:diveintomark.org,2004-05-27:1192 (ici <$MTEntryID$> vaut 1192)
    Ici, le seul problème potentiel est un manque de portabilité. Récemment, j'ai changé d'outil de publication, et l'imort/export n'a pas pris en compte ces clefs. Tous les ID de mes entrées ont été modifié. Je suis mauvais. Cette expérience a été en partie ce qui m'a incité à écrire ce tutoriel.

    Et bien sûr, si votre outil de publication n'utilise pas de base de données, alors cette technique n'est pas pour vous. Désolé, Rael.
  • Par date de création de l'entrée. Si, dans votre outil de publication, la date des entrées est immuable (autrement dit, une date qui ne change pas lorsque l'entrée est mise à jour, et qui n'est pas modifiable par l'utilisateur final), vous pouvez l'utiliser pour créer un Tag URI. Exemple :
    tag:diveintomark.org,2004-05-27:/archives/20040527110347
    Dans ce cas, la date de création de l'entrée était 2004-05-27 à 11:03:47. Les espaces ne sont pas autorisés dans un Tag URI, j'ai donc joint ensemble année, mois, jour, heure, minute et seconde.

    Ici, le seul problème potentiel est que vous devez garantir à l'avance que deux entrées ne seront pas publiées exactement au même moment. Dès lors, elles partageraient le même ID, ce qui va à l'encontre de l'objectif. Dans le cas d'une utilisation mono-utilisateur, ça n'est généralement pas un soucis ; et c'est ainsi que je génère mes ID désormais.

Que se passe-t-il si la même entrée apparaît dans plusieurs flux ?

Si la même entrée apparaît dans deux flux différents, elle doit avoir le même ID dans les deux. Ça n'est pas une exception à la règle "globalement unique", ça en fait partie intégrante. L'ID d'une entrée est la clef de cette entrée à travers le temps et l'espace. Si la même entrée apparaît à deux endroits, elle doit avoir le même ID partout — sinon ça n'est pas réellement la même entrée.

Quand cela pourrait-il arriver ?

  • Un site web qui classe ses flux par catégories, où une entrée apparaît dans plusieurs catégories
  • Les flux partagés, comme sur les sites du type « Planet XYZ » qui agrègent le contenu des sites de plusieurs contributeurs.

Dans le cas où un site web propose plusieurs flux, vous devez simplement faire attention à ce que chaque ID généré soit identique quelque soit le flux. Soyez sûr que l'ID ne soit pas basé sur l'URL du flux dans lequel il apparaît, ni du nom de la catégorie, ou tout autre donnée susceptible de différer suivant qu'elle soit dans un flux ou l'autre.

Dans le cas de sites qui agrègent le contenu d'autres sites, le script d'agrégation devrait préserver l'élément <id> original de l'entrée de chaque flux.

Comment les agrégateurs gèrent le duplica de données est à leur entière charge. Si une entrée apparaît dans deux flux, et que vous êtes abonnés aux deux, certains agrégateurs pourrait afficher l'entrée dans les deux, mais la marquer comme "lue" partout lorsque vous l'aurez lue une seule fois. Le comportement du logiciel côté client est entièrement à la merci du développeur qui l'a écrit. La seule chose que fait l'élément <id>, c'est de donner au développeur la capacité de prendre ces décisions sans complications ni erreurs heuristiques.

Résumé

Un ID Atom/RSS est un URI immuable, global et unique. Tous ces attributs sont importants. Si l'ID d'une entrée change constamment, ça va à l'encontre de l'objectif. Si vous réutilisez les ID pour différentes entrées, ça va vraiment à l'encontre du principe. Il y a plusieurs techniques pour construire un URI immuable globalement unique, et vous devriez choisir le plus facile pour vous.