On 04/07/06, Jan Algermissen <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
>
> Steve,
>
> (again) PUT *is* the operation and whoever implements the PUT on the
> lightbulb sould make
> damn sure it does the right thing (that is set the state with the
> entity supplied with the PUR request).
What is the real-world effect of calling PUT?
What is the business value of calling put?
Describing PUT as the operation is a bit strange to me as it has
neither value nor effect.
>
>
> On Jul 4, 2006, at 1:35 AM, Steve Jones wrote:
>
> > >
> > > 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.
> >
>
> PUT is the contract, yes. PUT means "replace state" no more,no less.
I thought it was request to change state?
>
>
> > 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.
>
> What if lightbulb.TurnOff() does cat >/dev/null? There is no difference.
Yup, this is my point. There is no difference between REST or SOAP
from the perspective of the consumer who care about the implemted
effect, not about the mechanism to get to that effect.
>
>
> >
> > >
> > > 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.
>
> Right, the contract is that after your PUT the state has been changed
> to whatever you sent as the body
> of the PUT. You can verify that with a GET afterwards.
Which is fine, but the effect may be more than just the direct state,
the post-condition may include the other direct, and indirect effects.
>
> What else can you want besides being able to test that the resource
> behaves upon PUT as required by the contract???
If I submit add an invoice (assuming that would be POST rather than
PUT) I'd expect that added to the database and the invoice ID to be
incremeted. If I change the state of an invoice to "OUTSTANDING" I'd
expect not only the state to change but also a reminder to be sent to
the customer.
>
> Jan
>
>
> >
> > >
> > >
> > > > > > 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/
