On 01/08/07, Jan Algermissen <[EMAIL PROTECTED]> wrote: > > > > > > > > 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.
It is 100% not a business interface, I know this for certain as no business conversation I've ever been in has used that sort of language. Its a TECHNICAL interface, the use of status codes, Mime-types and capitalised letters is a bit of a give away. > 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. > Nope a phone or a website is enough for me as a consumer to order a pizza, I phone up ask what they have got and then place the order. That is the business interface, the fact that the phone uses one set of technology and the web uses another is irrelevant to me as a consumer. > 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. > How? Seriously how on earth does a client know what a POST request will actually do? How do they know that POST, rather than PUT, is the right way to order a Pizza. How do they know that DELETE isn't valid once the order has been made? > 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. > I don't know, and I'm being crazy here, but maybe because people don't "submitData" to a Pizza company, they phone up and ORDER a Pizza, thus meaning that from a business perspective Giorgio's Pizza Data Submission Service gets zero orders a night while Luigi's Pizza Ordering Service gets loads. REST does not provide a business service interface in any way shape or form, it is purely a technology thing, the important interface is the one on the implementation which actually says what is being done and what is required. REST might be the best way to get the information from the consumer to the producer but it is about as important to the consumer and producers as the complexity of the phone network is to someone who wants to order Pizza. Steve > 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 > > > > > > > > > > > > >
