I already outlined that above.
Now how that behaviour for the duplicate URIs is implemented is a technical matter.
I’m curious how it would identify itself as a duplicate, is it via a header, as the only thing sent is, for example, an excel file?
A request going to resource/xlsx would get a response with a Content-Type of
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
and a Content-Location header of resource.
Of course that only makes sense if resource is capable of processing an Accept header for
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
to respond with that media type.
Well it’s excel, I don’t think it checks at all, it just downloads and uses it, and it wouldn’t use Content-Location either I’d imagine.
I do read your link the other way round. Content redirects to the path containing the format, but the format URL version has no way to link back.
I wouldn’t say this is used enough to be considered a best practice at all – and I don’t know if that would be the best for your case, but a “standard” way of describing URLs with client parameters is brought by the URI Template specification
Some examples:
http://example.com/~{username}/
http://example.com/dictionary/{term:1}/{term}
http://example.com/search{?q,lang}
That’s beside the point - i.e. that is Excel’s lookout. If it simply accepts what was dumped in it’s lap and only barfs when it can’t process the file … 
.
And while Excel may not care about the Content-Location something else might be by first sending a HEAD request and then not bother (because it already got resource) with a full GET.
Yes, you’re right. And the spec seems to read that way, i.e. pointing from the generic to the specific - which would be absolutely useless to establish the canonical URI.
Which would explain why search engines resort to
<link rel="canonical" href="http://www.example.com/product.php?item=swedish-fish" />
but that only helps with HTML - not with general HTTP responses.
I was lead by Restful Web services p.84.
The revised Restful Web API is contradictory p.324:
So that would only leave the redirects which is useless for avoiding the use of Accept headers.
Seems the canonical IRI has been pushed into Web Annotation Data Model (again not very useful for pruning unnecessary GET requests by using HEAD requests first).