On Wednesday, August 01, 2007, at 12:26PM, "Steve Jones" <[EMAIL PROTECTED]> wrote: >On 31/07/07, Mark Baker <[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. GET,POST,etc. *is* the business interface and the client knows what is going to happen based on its choice of the resource it invokes. That is why POST is enough to order a pizza: the client picks a resource that advertises the desired business semantics (here: a pizza order processor) and the uniform POST carries enough semantics to achieve the desired result. REST decouples object type from object interface but the object type is still used by clients - essentially, the act of picking an object of a certain type expresses the client's intent in a POST invocation. Why is that the better design in a decentralized context? Because unnecessary coupling is eliminated; who needs pizzaOrderProcessor.orderPizza() when one can have pizzaOrderProcessor.submitData()? Actually, if you look at object distribution patterns, they all tend towards that extreme but simply do not make the last (consequent) step. Cheers, Jan > >> 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. 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. > >> 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. > >> >> Mark. > > >Steve > >> -- >> Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca >> Coactus; Web-inspired integration strategies http://www.coactus.com >> > > > >Yahoo! Groups Links > > > > >
