RE: Representing Actions (was RE: AR023.7.1 (was Re: Dead trout

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