Closed ilyabirman closed 5 years ago
The way we dealt with that in RSS, in the <guid> sub-element of <item>, is to provide for an optional attribute, isPermaLink, that indicates if the guid could be used as a URL.
It seems to have held up pretty well over the years. :-)
Ideally, the id is the full URL of the resource described by the item, since URLs make great unique identifiers.
I also think that this is a bit fragile. This is what many blog engines do already when generating RSS and Atom feeds. The result is that when the blog owner does cosmetic changes to URLs (like how slug are generated, or adding the year in the URL), the ID of the item also changes in the feed. Which leads to reruns.
In my opinion UUIDs (in the form 956e4690-a9ae-4334-a83b-61ddc7b062f2
) are a good solution to this problem.
It's a good point that sometimes URLs change when migrating blog systems, for example, but a UUID or post ID seems unlikely to survive a migration like that. I don't think we can dictate that a more unique ID is used because it wouldn't drop cleanly into existing blog systems. Even with the downsides of using URLs, I think they are probably best for most people.
Currently it says: “Ideally, the id is the full URL of the resource described by the item, since URLs make great unique identifiers”. I’m afraid some developers may read this as “a good JSON feed has URLs in its feed IDs” and make their implementations depend on it.
I’d say it shouldn’t be the the URL, as the URL of the same item may change (i.e. when you fix a typo in it) and the ID should stay the same. I’m adding JSON feed support to my blogging engine, Aegea (http://blogengine.me/), and I want to use the unique numeric IDs for the posts.
So, I’d suggest changing the spec like this: “This may be the full URL of the resource described by the item if the URL is not about to change, or any other unique string. The JSON Feed readers should never count on this being an URL”.