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