On Jul 7, 2006, at 3:28 PM, Radovan Janecek wrote: > 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. >
That's probably true, Radovan, but I can no longer remember the origins of this thread ;-) All I wanted to point out is that the value of REST lies in the shared knowledge about the (different) core operations' semantics. I know you are aware of this, but I somehow feel some others aren't, even though they're arguing against the benefits. > 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. > OK, let's approach this differently, then - what, exactly, is the point of having an interface definition language if you're not generating code from it? Removing the operation part from the contract (because it's static in case of REST) means you only need to generate code for the different schemas (if you want to, which I'm firmly opposed to). There's tons of tools to do this (e.g. JAXB in Java) supporting XML Schema. Why would you need anything more if you fix the set of operations? Stefan > 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 Sponsor --------------------~--> Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/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/
