@galoisghost The reason why #1 might be right but #3 wouldn't would be because then you have more than one canonical path to the same object. That bothers me for some reason... and this isn't changing the object you're fetching, just how it's navigated.
I'm curious about seeing a lot of support for #3! I wasn't expecting the level of support we're seeing ;)
I'm curious about seeing a lot of support for #3! I wasn't expecting the level of support we're seeing ;)
While you're right about having a canonical URL, I offer two counter-points:
1) You're making the assumption that the resource in this case is the media item. It seems like it's the "media item in the context of a particular collection" :)
2) In the case of significant duplication of content at different URLs, rel="canonical" can help guide user-agents to the single "canonical" version.
As Mike points out, there's nothing magical about the query-string; it does sort of imply that you can chop off part of the URL to get the "real thing". But this is a slippery slope into the question of "is the URI the thing itself or a representation of a thing", so I'd just choose one and move on
1) You're making the assumption that the resource in this case is the media item. It seems like it's the "media item in the context of a particular collection" :)
2) In the case of significant duplication of content at different URLs, rel="canonical" can help guide user-agents to the single "canonical" version.
As Mike points out, there's nothing magical about the query-string; it does sort of imply that you can chop off part of the URL to get the "real thing". But this is a slippery slope into the question of "is the URI the thing itself or a representation of a thing", so I'd just choose one and move on