Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult to describe to the user agent, or when the server desires to send its “best guess” to the client along with the first response (hoping to avoid the round-trip delay of a subsequent request if the “best guess” is good enough for the user).
(my emphasis)
My reading of that is that its OK to serve different resolutions (or “representations”) from a single URI.
The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.
I guess this would entail the same additional HTTP requests that 302’s would.
Some very quick checking saw Firefox 8 deal with a 300 + location header sensibly (redirecting to the specified “default” location).
Chrome doesn’t redirect to that location, at which point this felt like a non-starter.
FWIW, the REST issue might not be a real problem after all.
According to the section of RFC2616 that deals with content negotiation:
(my emphasis)
My reading of that is that its OK to serve different resolutions (or “representations”) from a single URI.
HTTP Status Code 300 looks like an ideal response:
I guess this would entail the same additional HTTP requests that 302’s would.
Some very quick checking saw Firefox 8 deal with a 300 + location header sensibly (redirecting to the specified “default” location).
Chrome doesn’t redirect to that location, at which point this felt like a non-starter.