- From: Burdett, David <david.burdett@commerceone.com>
- Date: Wed, 19 Feb 2003 10:59:52 -0800
- To: "'Mark Baker'" <distobj@acm.org>, "Burdett, David" <david.burdett@commerceone.com>
- Cc: www-ws-arch@w3.org
OK, you might be able to use POST, but I think its meaning could be ambiguous as there are different things you can do with an order, for example: 1. Send it to a supplier so that they can check it and provide a response (as previously described) 2. Send it to tax calculation service, provides the taxes due in a response 3. Send it to an off-site archival service for long-term storage In all instances the content of the message is the same, but the action you are requesting is quite different. I don't think we could use POST for all three. For this reason I would think there would be benefit in defining new terms with appropriate semantics for each of the above such as: 1. PROCESSORDER - Check this request for goods or services and provide a response that indicates the extent to which you can satisfy it 2. CALCULATEORDERTAX - Check the taxes due on this order and provide a response that includes the taxes due 3. ARCHIVE - Store the content of this message securely and provide an identify by which it may later be retrieved Note that the first two are specific to the processing of an order and therefore dependent on the content of the message while the last one is generic and could apply to any message. Does this type of approach make sense? If it does then we can identify the principle that there the basic actions in REST which have their own specific semantics and then additional actions that can identify additional processes that are non REST that need to be invented when required. David -----Original Message----- From: Mark Baker [mailto:distobj@acm.org] Sent: Wednesday, February 19, 2003 10:34 AM To: Burdett, David Cc: www-ws-arch@w3.org Subject: AR023.7.1 (was Re: Dead trout On Wed, Feb 19, 2003 at 10:11:19AM -0800, Burdett, David wrote: > I really don't think that a simple REST interface is ideal in these > circumstances as you are not doing a PUT of the order to the supplier you > are really requesting an action that will result in a process being executed > that will return a set of information that reflects the results of that > process. Right, PUT's the wrong method in this case. It appears as though POST would be the appropriate method to use. > I think that we should recognize that this type of problem is going to be a > very common use case for "web services" and allow both REST and non-REST > approaches to both exist. > > One possible way to do this might be to: > 1. Define the REST "verbs" as the normative set of verbs to be used > 2. Allow additional verbs to be added as required. > > Thoughts? REST already allows new methods to be defined, so long as they are uniformly meaningful to all resources. But assuming you meant non-uniform methods (like those defined in WSDL docs) then sure, that's a good idea, and is really what I was trying to accomplish by proposing AR023.7.1[1]; provide early and late bound access to the same services, and let them duel it out. So it sounds like you and I agree that GET, PUT, and POST (in the abstract, not necessarily as defined in RFC 2616) constitute such a late bound interface. This would certainly meet the requirement. What do others think? [1] http://www.w3.org/TR/wsa-reqs#AR023.7.1 MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Received on Wednesday, 19 February 2003 14:00:26 UTC