Setting the state of the trout pond vs invoking the CleanTroutPon d method (was RE: Dead trout)

>  
>  
> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org] 
> Sent: Wednesday, February 19, 2003 12:02 AM
> To: Geoff Arnold
> Cc: www-ws-arch@w3.org
> 
> 
> This is so meta. 8-)

I don't think so.  This is the essence of the SOA "vs" REST debate that has
gone on for more that a year.  RESTifarians start with resources and state
transfer as if setting the state of the trout pond resource to "AllLiving"
cleans out the dead ones, and how that happens is an implementation detail.
SOA people start with whatever service actually removes the dead fish (some
guy named Joe, let's say) and treat the mechanism by which somebody tells
Joe to clean out the trout pond as an implementation detail.

I think the road to reconciliation along the lines of what David Orchard
suggests -- we need to model the fact that at least some services are not
"on the Web" (Dan Connolly's wretched car notwithstanding!) and can only be
accesseed by some sort of gateway.    

> How about this;
> 
> DELETE http://example.org/pond/trout/?status=dead

Uhh, there's an impedance mismatch between the physical trout pond and the
Web representation of it.  That DELETE request will surely time out in the
time it takes Joe to scoop out the dead fish!  In this particular case, it
probably DOES make more sense to model the interaction between the "Trout
Pond Manager Client" and the physical trout pond via requests to perform an
action ("methods") rather than exchanging state representations.  

> 
> 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.  You've been on the Web too long, son :-)  There *is* a
Real World out there.  As I found out to my regret yesterday, setting the
state of a Web resource that says I have an electronic ticket on UA 376 from
Denver to Detrit doesn't mean a damn thing if they sold more tickets than
they have physical seats on the physical plane.  (They bribed somebody with
a hotel room and a free ticket that probably cost them more than I paid so
that I could finally take my physical seat, but that's another story).

Bottom line: at least SOME (a large class of interesting examples!) Web
services use cases involve "services" that are performed out in the real
world.  It is probably possible to model all these RESTfully, e.g. instead
of DELETEing the virtual dead fish PUT-ing the state of the trout pond to
"CleanupInProgress" and Joe will set it to  "Clean" when he's done.  (Not
sure whether we need a God to set it to "Unclean" when the next fish dies or
what).  But I've seen no plausible argument that "CleanTroutPond(Joe)" is
not a good way to model this class of problems.

Received on Wednesday, 19 February 2003 09:28:38 UTC