Support link relations

[voxpelli]

There are lots of link relations that have been defined and which can be used to add additional metadata to links and link contexts and link relations have shown to be a powerful way to easily and independently extend formats and have them interact with other specifications through a shared basic semantic that enables it to support those other specifications without having to know any specifics about those other specifications.

Link relations are supported in HTML, Atom, HTTP (through Link-header), RSS (by using the Atom namespace) etc

The HTML spec points to the Microformats link relation registry for it's values: http://microformats.org/wiki/existing-rel-values

Historically there has also been a Link Relations spec that unified Link Relations across standards: https://tools.ietf.org/html/rfc5988

I would suggest supporting this at both feed level and item level through something like:

"links": [
  {
    "rel": "payment",
    "href": "https://flattr.com/submit/auto?url=https%3A%2F%2Fvoxpelli.com%2F2016%2F07%2Fbetter-handle-npm-modules%2F&user_id=voxpelli&title=3+tricks+to+better+handle+npm+modules&category=text&tags=blog&language=en"
  },
  {
    "rel": "webmention",
    "href": "https://webmention.herokuapp.com/api/webmention"
  }
]

The rel-payment mentioned there gained pretty good traction among mobile podcast clients that wanted to allow automation of sending of donations to Flattr.com after someone had listened though an entire podcast. It even got Instacast rejected from the app store. It truly showed the power of link relations when I, working at Flattr at the time, could just decide to utilize an existing link relation in places that allowed link relations and that way, without having to convince any specific feed format or feed parsers to add specific support for payment links, get a standard conformat format for donation links – a format that later eg. Gittip could pick and and support as well and more generic donation mechanisms be built around.

Allowing link-relations enables others to extend this format in similar ways in the future – adding capabilities that we either can't imagine right now or that are so obscure that we never will really care about it, but a minor sub-group of the community will feel that it adds a lot for them.

[aaronpk]

I like the idea, but I would suggest not using the property name links. My concern is that it could be misinterpreted that you're supposed to put all links on the page into that array. The Microformats2 JSON format has been using the property rels for this purpose for many years. That way it's mostly self-descriptive as to what you're supposed to put in it.

[nickshanks]

Have only 4 top-level keys. Values of keys "title", "description", and "comment" are strings. A new key "links" (or "urls" if you prefer) is an object. Each key of "links" is a relation (IANA or custom URI relation). Values can be strings (must be URL), array of strings, object with required "href" and optional other fields e.g. "title", or an array of such objects. "feed_url" becomes "self", "home_page_url" becomes "top" or "start", "items" becomes "item".

Now you have a very simple format that is extensible and hypermedia-compatible.

[dret]

one more data point: HAL uses a _links member for the same purpose. http://stateless.co/hal_specification.html