Re: AR023.7.1 (was Re: Dead trout

On Wed, Feb 19, 2003 at 10:59:52AM -0800, Burdett, David wrote:
> 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

Sure.  To distinguish between these things, you'd still use the POST
method, but you'd just POST to different URIs identifying those
different actors you mentioned (though much more granular than that
wording suggests, as you'd have to send it to a supplier's "checking"
resource, not just to some single URI where everything goes).

> 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.

The method, body, and headers of the messages may be identical, but the
URI would be different.  Like putting an "I love you" message in different
mailboxes will have different results. 8-)

> 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

Or how about just defining different types of resources, for example
an OrderProcessor, Archiver, etc...  Then, knowing the type, you could
just POST your order to it.

> 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.

Right.  POSTing a vCard to an OrderProcessor would presumably result in
a 4xx error of some kind.  But POSTing to an Archiver, you could get
back a 201 which would provide the resulting URI of the archived
document in the response.

> Does this type of approach make sense?

*nods* Definitely, modulo the URI issue.

> 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.

Well, let's see what you think about the varying-URI idea...
I'm not against what you're suggesting, I'm just hoping you can see the
additional value in what I'm describing.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Wednesday, 19 February 2003 16:25:28 UTC