On 7/28/07, Steve Jones <[EMAIL PROTECTED]> wrote: > > No, it's just a permissions problem. If you tried to call > > getSensorValue() on a sensor but received a permission fault in > > return, would you say that wasn't "valid"?. It's not like we're > > trying to call feedDog() on the sensor, which wouldn't make any sense. > > But I thought we'd already agreed that for some things a "DELETE" > doesn't make sense? It isn't about permissions (as that implies that > someone else could do it), its actually that there are certain things > where a DELETE request doesn't make sense (e.g. DELETE Energy).
No, I didn't agree to that. There is nothing upon which a DELETE doesn't make sense. As I said before, DELETE requests that *representations* be deleted, not the resource itself. So "DELETE energy" means "delete all representations of energy you possess". > > No, of course not. But if a method isn't supported, 501 can be > > returned; the interface itself accomodates the lack of an available > > implementation of a method on a particular resource. The method still > > makes sense on that resource. > > Makes sense but isn't supported? A bit of a contradiction in terms > there surely? Either it makes sense (and therefore should be > supported) or it doesn't make sense and therefore isn't supported. It *is* supported, it just isn't implemented. Remember, we're talking about interface here, not implementation. What any particular implementation does or doesn't do is not our concern, except insofar as we need the interface to support all possible implementations. Seeing as we can't possibly expect every resource to implement all methods - even if we just consider extension methods (which haven't been defined at the time the implementation is created) - then the interface needs to support a means of saying "No implementation of this method available for this resource". > > > The bit I find strange is how an interface can claimed to be uniform, > > > but the resources don't have to implement all of the interface. > > > > Another way to look at it is that what individual resources do or > > don't do is an implementation detail, and therefore separate from > > interface. > > Which is fine, and indicative of the fact that REST provides a > standard mechanism for shifting information between producer and > consumer but the real operational interface (i.e. what actually > happens) is the responsibility of the implementation Yes. > and it is that > which the consumer is actually interested in. No. Consider the canonical polymorphism example, of draw() invoking either drawCircle() or drawRectangle() depending upon the type of the object. If a consumer has a handle to a Rectangle object, does it care that drawRectangle() is the "real operational interface"? No, of course not, it only knows about draw(). Similarly, if an HTTP consumer calls GET and the server invokes getStockQuote() behind the scenes, what is the HTTP consumer actually interested in? Right, GET; getStockQuote() is completely hidden from it. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
