- From: Burdett, David <david.burdett@commerceone.com>
- Date: Wed, 19 Feb 2003 10:11:19 -0800
- To: "'Mark Baker'" <distobj@acm.org>, Geoff Arnold <Geoff.Arnold@Sun.COM>
- Cc: www-ws-arch@w3.org
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