Creating hypermedia links in a custom media-type Creating hypermedia links in a custom media-type xml xml

Creating hypermedia links in a custom media-type


I believe semantically your two Atom examples are equivalent. There are a few places in the Atom spec where a link with no relation is considered the default link (whether they call is "self" or "source" I don't remember). Personally I like the second AtomPub example the best, because the link elements in an Atom Entry (which is the most used object when dealing with Atom in general) defines link elements with relations, and using the same schema in category, collection, and workspace elements means it's easier to parse w/o needing to know a lot of special conditions.

I kind of ignore the first HTML example because original HTML was never really intended for machine communication in the way Atom is, and therefor (IMO) semantically understanding HTML is more difficult and waters down to a lot of specific rules to handle every different kind of tag.


What I liked about XHTML 2 was that every element could have a link.

Why not leverage XLink to enable the same funcitonality? That way, no need to choose.


Thats an interesting question. One way to look at it would be todifferentiate links into "informational" links that link to related resources,that the client may (or may not) want to follow to get more information(like the <categories> element in atompub).

On the other hand are the links that "define" the protocol,i.e. that "guide" the client through the sequence of state changes(e.g. publish/edit/delete in the case of Atompub, or order/review/pay in a shopping system) of a resource that make up the actual protocol (like<link rel="edit">).

In the Starbucks article, the authors expand the whole idea bydefining a (hypothetical) schema for state changes. They're using <nextrel="schema url" uri="uri for next resource state"> instead of Atom's<link rel="..." href="...">, but the general idea is the same.

Of course, one could argue that following any link represents a statechange for the client. But I think this distinction makes sense.