On 8/1/07, Steve Jones <[EMAIL PROTECTED]> wrote: > Its not really interface v implementation, its technical interface > (GET, POST, DELETE, PUT) v Business Interface (what actually is going > to happen). Consumers are only actually interested in the later and > the former is purely the mechanism for accessing it.
"what actually is going to happen" is an implementation artifact, not part of any interface, business, technical, or otherwise. You never want to expose implementation details because consumers tend to forge dependencies upon them, preventing the implementation from changing in ways which break those expectations. > > If a given resource can't be > > deleted, then the server need only return a 405 response when > > requested to delete it. So it "makes sense" in the sense that the > > meaning of a "DELETE http://example.org/some-trade"; message is uniform > > and understood by all parties. > > This really is contorting reality to fit the technical design. To say > that the "Meaning" of delete is that it may or may not happen is a > trifle odd. I didn't say that. I agree it would be odd (more than a trifle even!) because it would be defining the meaning in terms of implementation rather than interface. > If you ask people what DELETE means then they will say > that it removes and destroys the resource. The semantic of the > operation should be what its real-world effect is. It is, though the explanation of why gets a bit philosophical. The argument is that removing all representations of something is indistinguishable from removing the thing. It's much easier to see this for the other methods. But I agree with you in general. > > > That doesn't mean every resource can > > be deleted though, which is part of the reason why HTTP defines the > > 405 status code. > > That is a runtime thing, which is not part of the interface from a > consumers perspective when they design their interaction. This isn't > an effective, or acceptable, way of understanding what is valid for a > given system. The effort of coding a system that can, for all > resources, cope with 405s is just wasted effort. The consumers would > need this information published in advance, and would therefore not > call DELETE, therefore (for the consumers) the DELETE message does not > exist as a valid call. No they wouldn't need it published in advance. That provides no benefit, and indeed is counter productive because it more tightly couples clients to servers. We might not agree what "uniform interface" means, but there's no arguing that HTTP defines *an* interface. That means that in order for components to communicate, clients should be developed to the interface - the HTTP specification - not to a feature specific only to some resources, like whether or not a resource can be deleted. This thread began discussing "uniform" though, and it seems we've veered slightly off course. Perhaps we can try and steer it back. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
