On 04/07/06, Mark Baker <[EMAIL PROTECTED]> wrote: > > > > > > > > I note that we've got two parallel discussions on pretty much the same > topic here. If you want to pick one to respond to and ignore the > other, feel free. I won't take offense 8-) > :)
> > On 7/3/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > > > 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. > > > Well, it removes any ambiguity about what the message means; PUT "1" > means. What happens is up to the server, although the server > shouldn't do something that is inconsistent with the meaning of the > message and respond as if it didn't. i.e. if it can't turn the > lightbulb on, it shouldn't respond with a failure response. Which is fine and dandy, but not actually relevant to the consumer. What they care about is the effect of the call, the mechanism used to achieve those ends is of very secondary importance and the basic rule is good enough is fine. > > > > > > 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. > > > PUT *requests* that. I agree the implementation *does* it. Which was all I was trying to say. A consumer cares only about the actual effect, they don't care about the mechanism. > > > > If PUT just does "cat >/dev/null" then its not > > delivering the capability as required. > > > Right. And so the server sitshould return a 5xx response if that's > its implementation, because that tells the client that while it > understood the request (because it's not 4xx), it wasn't able to > perform the request. But as a consumer who doesn't want to understand HTTP I should just get a failure message, bit like an exception really. We don't want everyone to have to understand HTTP return codes. > > > > > 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. > > > I know. It confused me completely many years ago when I was > confronted with the same situation. I was a CORBA guy back then. > > > > 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. > > > Hmm, I'm not sure how I could be interpreted to imply that. But > perhaps I did, I don't know. But that's not the case. If the server > responds to a PUT request with a 2xx, then the client *knows* (unless > the server's lying, of course), that the state of the resource was set > to that represented in the body of the PUT request. Which was the bit I'm trying to get across in saying that SOAP v REST is a pointless debate. The consumer of the service cares only about what happens, not about the mechanism to achieve it. I'm not arguing that REST is wrong and should never be used, just that its not actually important enough to argue over the bit in between. Consumers care about what happens. > > > > > > 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? > > > Why is any operation idempotent? Because of what it *means*. Which again is part of the point (BTW what happened to re-entrant as a term?) you've but some application semantics onto these elements, which the consumer really doesn't care about either. Its _your_ choice to say that POST/PUT have different semantics but as a consumer I don't care what technical implementation you chose to use, I just care that stuff happens how I expect. (Does raise the question as to how you would do POST async which was where we came from around this) > > getStockQuote is likely idempotent because you'd expect such a name to be > safe. > setDesiredTemperature() is likely idempotent because one would expect > that name to be. > processInvoice() is likely non-idempotent for the same reason. Yup, which is why I like good old Bertrand Meyer's Design by Contract ideas, which are things that can help a consumer. I can define the pre-condition, post-condition and the invariant which will further help the consumer understand the service. > > > >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. > > > I don't see how POST prevents asynch. One of the previous suggestions was to use client side polling to simulate async submission/response, that only works with idempotent approaches. None of the suggested approaches worked (IIRC) if the mechanism wasn't idempotent. > > > > > 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. > > > Yes, well said. I didn't say it didn't have its drawbacks. 8-) > > > > Hint of the day: REST isn't the silver bullet. > > > Never said it was. It's just offers a much simpler, more scalable, > more secure, more reliable architectural option for building large, > data oriented applications. And here I'll have to disagree, firstly because I still don't see it in my world as an architecture, and secondly I still haven't seen a single thing with REST that can't be done equally well by shifting CSV down a Unix Pipe. I'm not arguing that REST is rubbish, just that its not actually special (or IMO new) and if you believe that the technical implementation of systems is the most important challenge then you will fall into the oldest trap of IT. > > Mark. > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> See what's inside the new Yahoo! Groups email. http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> 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/
