Re: Resource definition

> Secondly, simply telling the resource that the light is on is not 
> equivalent to actually switching the switch!

That's true.  If you're interested in the state of the switch and not
the light, then you want a switch resource, not a light resource.  But
in the familiar case, the state of the light is what the client cares
about, and the switch is...implementation detail.

This raises an important point. In most applications I have experienced
and most I can conceive of, clients understand the problem domain
in terms of the state of domain objects.  They don't want to toggle the
switch, they want the light on.  They don't care what starting state it was
in.  This is too prevalent to dismiss.

Things which are operation-centric and state-agnostic tend to be
games, not businesses.  Picture a child flipping the switch merely for
the sake of changing its state.  Clearly, the more goal-oriented the
endeavor, the better state-transfer fits.

Walden