La création de liens hypermédia dans un type de support sur mesure

Question

Je crée actuellement un ensemble de types de supports personnalisés pour une api RESTful (par exemple application / xml vnd.mycompany.foo +) et je suis en train d'identifier les avantages et les inconvénients de deux façons différentes d'exposer les liens hypermédia.

Si je considère d'abord ce que les autres types de médias font probablement le meilleur endroit pour commencer est HTML. Html me permet de créer des liens tels que:

<image src="http://example.com/image.gif"/>
<a href="http://example.com/page.html"/>
<form action="http://example.com/page.html"/>
<link rel="stylesheet" type="text/css" href="theme.css" />

La chose intéressante est que, dans certains cas, il y a quelques balises spécifiques qui ont un attribut url et puis il y a la balise de lien générique qui en utilisant l'attribut rel pour définir la relation.

Dans AtomPub, il y a aussi quelques façons que les ressources sont reliées entre elles

<collection href="http://example.org/blog/main" >
         <atom:title>My Blog Entries</atom:title>
         <categories href="http://example.com/cats/forMain.cats" />
</collection>

<atom:category scheme="http://example.org/extra-cats/" term="joke" />
<atom:entry>
   <link rel="edit" href="http://example.org/edit/first-post.atom"/>
</atom:entry>

La question que je pose est quand est d'ajouter un attribut à un élément existant, il est plus logique d'utiliser un élément de liaison avec une relation, et quand est-il plus de sens.

par exemple. les liens AtomPub aurait pu être fait

<collection>
      <link rel="source" href="http://example.org/blog/main"/>
         <atom:title>My Blog Entries</atom:title>
         <categories>
                <link rel="source" href="http://example.com/cats/forMain.cats"/>
         </categories>
</collection>

<atom:category term="joke">
     <link rel="scheme" href="http://example.org/extra-cats/"/>
<atom:category>
<atom:entry edit="http://example.org/edit/first-post.atom"/>

Comme il est souvent le cas, par écrit cette question, la réponse semble maintenant évidente. Les liens nécessaires sont exposés sous forme d'attributs et les éléments optionnels comme. Cependant, je serais très intéressé à entendre les opinions des autres sur la façon dont ils pensent les liens doivent être représentés.

Answer 1

Ce que j'aimé XHTML 2 est que chaque élément pourrait avoir un lien .

Pourquoi ne pas tirer parti XLink pour permettre la même funcitonality? De cette façon, pas besoin de choisir.

Answer 2

Je crois que sémantiquement vos deux exemples Atom sont équivalents. Il y a quelques endroits dans la spécification Atom où un lien sans rapport est considéré comme le lien par défaut (si elles appellent est « soi » ou « source » Je ne me souviens pas). Personnellement, j'aime le second exemple AtomPub le meilleur, parce que les éléments de liaison dans une entrée Atom (qui est l'objet le plus utilisé lorsqu'ils traitent avec Atom en général) définit les éléments de liaison avec les relations, et en utilisant le même schéma dans la catégorie, la collecte et l'espace de travail éléments signifie qu'il est plus facile à analyser w / o avoir besoin de connaître beaucoup de conditions particulières.

Je sorte d'ignorer le premier exemple de HTML parce que le HTML originale n'a jamais été vraiment destiné à la communication de la machine de la manière Atom, et à cet effet (OMI) HTML sémantiquement la compréhension est plus difficile et les eaux vers le bas à un grand nombre de règles spécifiques pour traiter tous les autre type de balise.

Answer 3

Thats une question intéressante. Une façon de regarder ce serait différencier des liens en liens « d'information » qui pointent vers des ressources connexes, que le client peut (ou non) veulent suivre pour obtenir plus d'informations (Comme l'élément de <categories> dans AtomPub).

D'autre part sont les liens qui « définissent » le protocole, à savoir que « guider » le client à travers la séquence de changements d'état (Par exemple publier / modifier / supprimer dans le cas de Atompub ou commande / révision / payer dans un système commercial) d'une ressource qui composent le protocole réel (comme <link rel="edit">).

Dans l'article Starbucks , les auteurs développent l'idée par la définition d'un schéma (hypothétique) pour les changements d'état. Ils utilisent <next rel="schema url" uri="uri for next resource state"> au lieu de Atom de <link rel="..." href="...">, mais l'idée générale est la même.

Bien sûr, on pourrait dire que suivant tout lien représente un état changer pour le client. Mais je pense que cette distinction est logique.