| Thread Previous • Date Previous • Date Next • Thread Next |
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.
| Thread Previous • Date Previous • Date Next • Thread Next |
