RE: AR023.7.1 (was Re: Dead trout

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