Now remember be easy on me because I'm thick....
On 02/07/06, Mark Baker <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
>
>
> On 7/2/06, Steve Jones <[EMAIL PROTECTED]> wrote:
> > On 02/07/06, Mark Baker <[EMAIL PROTECTED]> wrote:
>
> > > Sure, but your service oriented approach also has to define those
> > > things *and* the operations. That's extra agreement that my solution
> > > doesn't require, because my solution reuses existing pervasively
> > > understood operations. I'd call that simpler.
> >
> > Err not quite. You've already defined the "on/off" operation, and
> > suggested that there is a dimmer switch as well. This means that via
> > the PUT you have defined two operations, which is exactly the same
> > number.
>
>
> No, the operation in both cases is PUT. "on" and "off" are
> representations of the desired state. They could be "0" and "1", or
> even pictures of lightbulbs in the on or off state.
>
>
> > The call isn't the operation, its the real-world effect that is the
> operation.
>
>
> No, that's the implementation; what some code behind the interface
> does when you use the interface. The operation is part of the
> interface.
Now this is the bit that really confuses me. What you appear to be
saying is that calling PUT removes any responsibility from either
caller or consumer around what happens as PUT is the important thing.
When I call Lightbulb "off" in what ever way then I expect the
lightbulb to go off. PUT does not do that, its the implementation
that does that. If PUT just does "cat >/dev/null" then its not
delivering the capability as required.
>
> I hope you're not suggesting that clients should depend on the
> implementation of the service!
Nope, but they should depend on the real-world effect (post-condition)
of the service.
>
>
> > > > IOW, you need to define the contract. If you don't, the two
> approaches aren't comparable. If you do, they are more or less equivalent.
> > > > BTW, in your setup, how would you make the interactions
> asynchronous?
> > >
> > > The bulb could return a 202 to indicate that it will process the
> > > request some time in the future. Or the client could just
> > > fire-and-forget the request, and then reuse the fact that PUT is
> > > idempotent to resend,
> >
> > PUT is idempotent, but that does not guarentee that the operation on
> > the lightblub is.
>
>
> Yes, it does, because PUT is the operation.
>
> I know, a protocol defining an application layer operation? Crazy,
> eh? Well, no. That's called an application protocol, and they have
> nothing whatsoever to do with transport protocols, except for the fact
> that they share the name "protocol".
And this is the bit that confuses me completely.
You seem to be implying that "PUT" has no requirements to deliver the
required functionality and that consumers should be happy with that.
If PUT doesn't give you the real world effect then its pointless, you
might as well ping random bytes around the internet as its got the
same chance of success.
PUT as an operation, which guarentees no actual result doesn't make
much sense to me.
>
>
> > As an example lets say instead of it being a
> > request for off/on its a request to turn the lightbulb down by a
> > "quarter turn" of the dial. Multiple calls would then result in the
> > knob being turned off the wall.
>
>
> Then I'd use POST for that, not PUT. But POST is not idempotent.
Why? Other examples would be the submission of an invoice, the
submission of receipt and various other elements, so as soon as you
are talking about POST then the ability for async appears to
disappear.... which to be blunt means the approach is bollocks.
>
> Another option would be to first GET the representation of the state
> of the bulb, do the calculation of a "quarter turn" myself, derive a
> new representation of that state, then PUT it back to the lightbulb.
Or in other words push the assesment back onto the consumer and
increase the level of coupling between the two. Which increases the
dependencies and the fragility of the system.
N.B. This is not unique to REST its equally applicable to the same
solutions using SOAP/WSDL
Hint of the day: REST isn't the silver bullet.
>
> Mark.
>
>
>
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
