Erik Hetzner <erik.hetzner <at> ucop.edu> writes: > > At Mon, 8 Oct 2007 17:35:00 +0000 (UTC), > Sean Landis <sean.landis <at> gmail.com> wrote:
[...deleted...] > > I'd say that Restlet meets the requirements of the spec and that's > > good. Although I still think it would be better to leverage Uniform > > entirely and it seems awkward to me that HEAD is an exception. > > > > My understanding of REST is that HEAD is part of the uniform > > interface and therefore should be supported in the same way, and to > > the same extent as the rest of the HTTP methods. I was very > > surprised when HEAD did not conform to the programming model in > > place for the uniform interface and I suspect others would be too. > > I don’t understand what you mean here by uniform interface. Uniform > interface in REST refer to inter-application semantics, not > intra-application. And it doesn’t, to my understanding, mean that HEAD > & GET must have identical semantics, rather that the semantics of a > GET or HEAD request be the same for all resources. Am I > misunderstanding you here? I don't know if Jerome's comment clarified so I'll follow up. The Resource class partially supports methods that map to a uniform interface (GET,PUT, POST, DELETE, HEAD, OPTIONS). The confusion is that, although there is put(), post(), and delete(), there is no head() (or options() or get() for that matter). There is an allowGet() method, but no get(), which seems even more strange. OPTIONS seems to have been entirely left out. (BTW, I am using p. 97 of "RESTful Web Services" as my definition of the uniform interface). My point is that the internal implementation of the uniform interface ought to be consistent. The head thing is very confusing because, not only is there no head() but there is behind-the-scenes magic that removes the content. (Based on what's been stated about curl behavior, it sounds like there are cases where content might be desired?) We have about a dozen people writing web services using Restlet. Although head is confusing, I'd say we experience more confusion over the fact that GET is a 'special case'. That is, there's no get(), but instead you must use getRepresentation(). So far, every single developer here has stumbled on this and required explanation. I'm afraid I can't give a rationale, I just tell them that's the way it is. Sean
