[stanleydrew]

"Because according to the spec, each resource is named by a single URL, so two URLs name two different resources."

I don't think this is technically correct. For instance, you might have a blog with a post at /blog/2011/07/03/why-i-love-rest and you might have /blog/current represent the same resource until you post something new. This seems like a valid case in which two different URIs name the same resource.

If you are versioning the resources themselves I think the version in the URI is perfectly fine. In reality this is almost never the case and people mainly use the version in the URI to designate different versions of the representation. This is bad since it ties the URI to the representation which is a big no-no.

[icebraining]

Hmm, I think that those URLs are still different resources; one is 'the current post' and the other is 'the post named "Why I love REST"'. I would do a 302 from the latter to the former.

[stanleydrew]

Ah, fair enough. They are indeed two different resources. Would you have a problem if I returned the actual representation rather than a 302?

[icebraining]

I don't have a 'problem' with it, this is just conceptual talk. But I'd still do it for SEO reasons.

If Google fetched /blog/current as containing the "Why I love REST" post and showed it to me, and the when I clicked the link I got "Why I think turtles are awesome", I'd be annoyed. A 302 fixes that in a more clean way than entries in robots.txt or similar tricks.

EDIT: Apparently Google messes that up and often associates the content with the source URL and not the destination URL. Disregard the previous paragraph.

[dedward]

Seems like people are mixing up ways of providing web services with overall site design and url friendliness......