RE: Dead trout

Mark

You said ...

>>>For some actions, you may have to jump through hoops to render that
action via uniform semantics.  In those cases, it could be that the benefits
of the uniform interface aren't worth the cost.

But before anybody jumps on that with "Aha!  Web services are for those
cases!", I'd point out that it's very uncommon to find such an action in
practice.<<<

I beg to differ.

Although I agree there are many, many circumstances where a uniform
interface is both applicable and useful, there equally many uses where they
are not.

My focus is on how to make "web services" work in an B2B or EAI environment
where the semantics of what you are asking the recipient of a message to do
are not a simple request to change the state of an object. For instance take
the very simple idea of sending an order to a supplier and asking them to
send a response back. At the supplier end, this can involve:
1. Checking that buyer is known and has a good credit rating
2. Checking that the products ordered are in stock
3. Scheduling manufacturing or out-sourcing of out of stock items, or
placing them on back order
4. Checking if delivery can be made when requested
5. Scheduling one or more deliveries
6. Providing a response back to the buyer with information that totally
depends on the outcome of the previous steps.

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.

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?


David

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Tuesday, February 18, 2003 9:02 PM
To: Geoff Arnold
Cc: www-ws-arch@w3.org
Subject: Dead trout



This is so meta. 8-)

On Tue, Feb 18, 2003 at 10:35:40PM -0500, Geoff Arnold wrote:
> Representing action as state transfer is unnatural in many situations and
> wholly impractical in others. For example: consider a TroutPond resource
> which contains an arbitrary number of Trout. How, pray, do you render
> the action RemoveAllDeadTrout() as a state transfer?  One could,
> I imagine, HTTP GET the entire pond state, compute the subset pond
> containing only non-dead fish, and then HTTP PUT the result, but
> idempotency, scalability, and common sense would seem to rule that out....

How about this;

DELETE http://example.org/pond/trout/?status=dead

But sure, I understand your point, as you're preaching to the choir.
For some actions, you may have to jump through hoops to render that
action via uniform semantics.  In those cases, it could be that the
benefits of the uniform interface aren't worth the cost.

But before anybody jumps on that with "Aha!  Web services are for
those cases!", I'd point out that it's very uncommon to find such an
action in practice.

BTW, despite what I said, REST (and despite the name 8-), isn't
constrained to effecting change via state transfer.  The important
constraint from an architectural POV, is uniform semantics.  The state
transfer quality of the style is a side effect of this constraint,
as all resources have state that can be transferred.

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

Received on Wednesday, 19 February 2003 13:12:09 UTC