Re: [service-orientated-architecture] RESTful lightbulb

Mon, 03 Jul 2006 08:27:23 -0700



The lightbulb's desired state can be On or Off. But it can also be Hot or Cold. Or it can be Green or Blue. Or it can be Broken. Or it can be Big or Small. And perhaps many more I don't know about.

 

What to PUT is what Steve and many others including myself call 'operation'. No problem calling it 'desired state representation'. Just tell me what to PUT.

 

I understand it is possible to use RDF/XForms and similar to determine what to PUT at runtime. And it is definitely good idea. The problem is that then either the client applications have to be almost as good as HTML browsers or they have to have the implicit contract knowledge hardcoded. The HTML-browser-like setup is more loosely coupled than WSDL because all you do is dynamic introspection-based code (extended with semantics because there is no human sitting behind the Form). The hardcoded way is more tightly coupled because not only you hardcode some contract but the contract is also invisible.

 

Relying on HTTP has many advantages (ubiquity, proxies, caches, and so on). So why, if there are so many advantages, everybody focuses on this apparent disadvantage (at least from enterprise development POV)?


Radovan (http://radovanjanecek.net/ablog/mt-search.cgi?IncludeBlogs=2&search=REST+AND+CONTRACT)


On 7/2/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.

I hope you're not suggesting that clients should depend on the
implementation 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".


> 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.

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.

Mark.




--
Radovan Janecek
http://radovanjanecek.net/blog __._,_.___


SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to