- From: Mark Baker <distobj@acm.org>
- Date: Wed, 19 Feb 2003 13:33:30 -0500
- To: "Burdett, David" <david.burdett@commerceone.com>
- Cc: www-ws-arch@w3.org
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 13:30:38 UTC