- From: Burdett, David <david.burdett@commerceone.com>
- Date: Wed, 19 Feb 2003 15:07:05 -0800
- To: "'Mark Baker'" <distobj@acm.org>
- Cc: www-ws-arch@w3.org
I'm changing the email subject since I *think* we have reached consensus that POST, on its own, is not enough. There needs to be some additional metadata, that has to be represented somewhere on the message, that identifies the actor or the action that is to be carried out on the message. I will try and enumerate several of the potential ways of representing the action so that we can debate the alternatives ;). They will all assume an order sent to example.com. VARIANT 1 - HTTP relative path POST http://ecommerce.example.com/processorder VARIANT 2 - HTTP Query POST http://ecommerce.example.com?action=processorder VARIANT 3 - Separate Server POST http://processorder.example.com VARIANT 4 - New HTTP Method PROCESSORDER http://ecommerce.example.com VARIANT 5 - SOAP Role POST http://ecommerce.example.com <SOAP:Envelope> <SOAP:Header role="urn:.../processorder"> </SOAP:Header> ... </SOAP:Envelope> VARIANT 6 - SOAP Header POST http://ecommerce.example.com ... <SOAP:Envelope> <SOAP:Header role="messagehandler"> <x.Actor>processorder</x.actor> </SOAP:Header> ... </SOAP:Envelope> VARIANT 7 - SOAP Body POST http://ecommerce.example.com ... <SOAP:Envelope> <SOAP:Header> ... </SOAP:Header> </SOAP:Body> <y.Order type="processorder"> ... </y.Order> </SOAP:Envelope> Are these enough, or are there further reasonable examples to consider that I've missed? Please suggest more if you can think of any. MY PERSONAL PREFERENCES My personal preference is for variant 6 (sorry Mark it's not URI's!) and here's why ... All the options that involve putting information in the URI (Variants 1 through 4) mean that the data is visible to anyone who sees the information go over the net. While this might not often be a worry sometimes it is. The simple fact, for example, that Microsoft was placing an order with Sun (or vice versa), could be the basis of some very interesting articles ... not that I am suggesting that either would do such a thing ;) On the other hand, if the data is recorded in the body of the message somewhere then it can be encrypted which helps ensure privacy. I'm not keen on Variant 5 (SOAP Role) as it means that, in theory, the message HAS to be handled by a SOAP node that can accept an order, unlike Variant 6, where you are targeting a SOAP node that can handle any message - it's my experience that, for eCommerce, having a general "front door" or gateway that can accept any eCommerce message is what implementors want to do as it makes it easier for them to put all the security, firewall protection, message logging, etc, in a single place. I'm also not keen on Variant 7 as the data is buried in the body of the message which means that you cannot work out what to do with the message unless you understand the semantics of the body of the message. So Variant 6 is the one I prefer. What do other people think? David -----Original Message----- From: Mark Baker [mailto:distobj@acm.org] Sent: Wednesday, February 19, 2003 1:28 PM To: Burdett, David Cc: www-ws-arch@w3.org Subject: 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 18:07:44 UTC