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. > > 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. > 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. > > 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. > > > 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*. 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. >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. > > 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. Mark. ------------------------ Yahoo! Groups Sponsor --------------------~--> Check out the new improvements in Yahoo! Groups email. http://us.click.yahoo.com/6pRQfA/fOaOAA/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/
