openstack team mailing list archive

[Mark Nottingham <mnot@xxxxxxxx>]

On 28/10/2011, at 2:39 AM, Bryan Taylor wrote:

> 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 .

Yes -- but by their nature, intermediaries are really limited beasts anyway. You can address this by surfacing relationships in Link headers, and writing generic specs to exploit those links (this is how we did cache invalidation with LCI - <http://tools.ietf.org/html/draft-nottingham-linked-cache-inv-00>).

It comes back to the central question of utility -- what do you want those intermediaries to do? If they need visibility for a particular purpose, that's great, and we should design to be able to exploit this in the future as much as possible, but we can never offer them full visibility.


> 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.

As a limited tool that's used well, I have no problem with it. I do agree that having them spread over the interface like a thick layer of peanut butter makes me uneasy.

Cheers,


--
Mark Nottingham   http://www.mnot.net/