manton / JSONFeed

The JSONFeed.org website
Creative Commons Zero v1.0 Universal
942 stars 56 forks source link

Use 'feed' or other link relation for discovery? #73

Open baldurbjarnason opened 7 years ago

baldurbjarnason commented 7 years ago

There was a comment on a media type discussion that I think deserves to be its own issue:

The W3C and WHAT WG versions of HTML overloaded rel=alternate just for the media types application/rss+xml and application/atom+xml. If one of these is not there it means alternative representation of the current document, not "there is a feed for this blog". If a new media type get's registered, someone should also petition WHATWG and W3C for its inclusion in the HTML specs.

(There was a proposal of rel=feed somewhere. That proposal seems dead except for some usage for the HTML feeds of the Indieweb movement. Maybe that's easier)

https://github.com/brentsimmons/JSONFeed/issues/22#issuecomment-302592705

The reason why it's separate from the media type issue is that a 'feed' or 'jsonfeed' link relation has value in and of itself:

It makes feed discovery more reliable under circumstances where discovery based on media types is unavailable (e.g. due to server configuration or lack of resources) or complicated.

Having a link relation also makes it easier to use JSON feeds in other formats like ebooks or digital publications. For those, the current use of 'alternate' with an 'application/json' media type isn't really workable since many of these formats already have alternate json representations in different json formats.

Some of these problems would also be solved by having a new media type but I think there is value in having both a link relation and a media type in any case.

For reference:

Minting an extension link relation is much easier than registering a media type but might look odd to many:

<link rel="alternate https://jsonfeed.org" href="https//example.com/feed.json" type="application/json" title="My Feed">