Well, maybe. But I don't think this was why this discussion thread started. We wanted to know what to PUT in order to turn the lighbulb on/off.

We should find a way how to express higher-level contract for RESTful services. (what to PUT/POST etc). Then, because it would still be REST (or rather HTTP) we would keep the advantages (proxies, caches, ides, etc...). Maybe, the reality will teach us that the best way is just to formalize nothing and use out-of-band HTML documentation as it is the case today.

Radovan

On 7/7/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote:

On Jul 7, 2006, at 11:32 AM, Radovan Janecek wrote:

> Yes to all your questions.
>
> So what I call operation in this case is PUT <setOff/> or PUT
> <setOn/>.
>
> You apparently have one operation PUT <any/>. And you solve the
> problem of what to PUT at runtime.
>
> Radovan
>

I think this is somewhat analogous to the JavaBean convention:

setName()
setAddress()
getName()
getAddress()

have both a shared meaning (get retrieves and is safe, set is (like
PUT) idempotent and mutating), as well as a specific meaning (what do
they set).

Not entirely the same, but somewhat similar - the shared knowledge
enables tools such as IDEs to offer some generic functionality,
similar to HTTP proxies which could cache the result of GETs.

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/




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


YAHOO! GROUPS LINKS




__,_._,___

Reply via email to