Open Stack

On 10/26/2011 11:19 PM, Mark Nottingham wrote:
>> To be truly RESTful at the level of the Fielding article (which I
>> actually think is the best description of HATEOAS there is) you
>> shouldn't have these variants at all.  I worry about us trying to
>> put lipstick on the pig -- all these variants are a crummy
>> compromise to work around broken browsers that do allow changing
>> the accepts header.

> It's perfectly legitimate to link to a resource that has only one
> representation, such as having /foo.html to allow people to
> specifically refer to the HTML version of the /foo resource. That's
> effectively agent-driven negotiation, and it's just as valid
> (RESTful, if you will) as server-driven negotiation. Nothing that Roy
> has said contradicts that, because a core principle of REST (if we
> really want to go there) is that important things have identity, and
> that links are what drive things (agent-driven negotiation is just
> linking, really).

It harms visibility, a key goal of REST, especially if we are doing this 
on every resource. If I do a PUT to /foo.xml the intermediaries have no 
way to know that I'm really affecting /foo .

I've made the point before that I can define a resource to be anything I 
want, including a particular representation of another resource. I'm not 
opposed to using variants generally on the web, and Jorge's pdf example 
is pretty much impossible to do without them. I'm just questioning 
whether it makes sense to use them to solve our developer API 
introspection problem within our web service APIs.