On 30/07/07, Mark Baker <[EMAIL PROTECTED]> wrote: > > > > > > > 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".
This sounds like contorting reality just to make it fit into your conceptual model. I'm aware of that DELETE is a request to a representation, but I'm also aware that good systems tend to reflect the real-world rather than being purely IT. Thus if in the real-world it makes no sense to delete something then its a bad idea(tm) to model a deletion in the software. > > > > 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. That really doesn't make sense. If I am a consumer I want to know what the resource can do. Claiming that it "supports" something means that it "does" something. Its a strange definition of support that says "X supports DELETE" and when someone calls DELETE it says that it can't complete that request. > > Remember, we're talking about interface here, not implementation. I know. My point since day 1 in REST v SOAP has been that the important piece is the BUSINESS interface for something not the technical interface. What you are talking about is the technical interface. > 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". Which makes very little sense from a consumers perspective in terms of differentiating supports and implements, its like Microsoft saying that Windows Vista supports ZFS and then when someone tries to use that being told "not implemented". Microsoft would (rightly) never make that claim because they know it would be open to charges of fraud. If its not implemented by a resource then the resource _does not_ support that functionality. > > > > > 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. Which is what I've always said. I'm glad everything is agreed..... oh hang on it continues :) > > > 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(). Err that isn't a good example. You are talking about standard OO principles here and decent naming conventions. If I have a circle and say "draw" I will expect a circle to be drawn. If I say "draw on this piece of paper" and supply a piece of paper I will expect the circle on that piece of paper. If I can't request a specific piece of paper, I expect to be told what is allowed in terms of drawing surfaces. Rectangle v Circle is not what is important here. > 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. But the consumer does care if there is a GET on a stock that has a premium service in terms of data validity, it also cares if there is a GET for the stock that returns the market value and history. It cares if there is a GET against the stock that returns the latest news for that stock. These are the operational interfaces and this is what is important. Equally it is 100% important to known that DELETE is not available on trades, once you have committed a trade it exists for ever, there is no way to back-out so you should not design a system that commits the trade then says "are you sure" assuming that DELETE is allowed. DELETE is not allowed, and indeed makes no sense, for a trade that has already been committed. This is what is important. Does that example help more in understanding what I mean about why people care about the real-world effect of things rather than the technical interface? > > Mark. > -- > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca > Coactus; Web-inspired integration strategies http://www.coactus.com >
