On 29/11/06, Mark Baker <[EMAIL PROTECTED]> wrote: > > > > > > > On 11/28/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > > And if the publisher of the *same* functionality used this instead; > > > > > > http://example.org/kdjfalkjdfnawkflaudfnakjsdnfalufh > > > > > > then what would the operation be there? > > > > Incomprehensible to any rational person? > > 8-) It would still be GET.
So? > > Consider that you'd still receive the data you expected, but without - > using your argument - knowing the operation! How is that possible? > An essential aspect of distributed computing is that client and server > share a *contract*; if the client doesn't know the whole contract - in > this case the operation - then it isn't shared. Something else must > be going on! I wouldn't receive the data I expect as I would have no clue as to what data to expect via such a badly named element. You appear to be arguing that the client must know everything about the server, which means the two are tightly coupled which is a bad thing. I must be missing something here as you can't be suggesting that surely. > > > Quite clearly, because I thought that the major idea was that the URI > > was in itself documentation of the action. Okay so drawGraph should > > possibly be just "Graph" and viewing Graph as a resource, but what is > > wrong from a REST perspective with a resource of > > http://somewhere.com/maths/graph?x=mypoints&y=mypoints ? > > > > GET will be idempotent and is considering graph to be a complex resource. > > > > If you are saying that REST isn't that simple then I'm suprised. I > > was sure that choosing the right URI name was a key part of REST. > > It is, but it doesn't identify the operation, it identifies the > "thing" the operation is to be invoked upon. It's an object id. So "graph" isn't a resource? But "GraphId452354" would be? I have to say in my reading of REST so far its the former that I've understood (and sometimes liked) while the later would just be rubbish as you'd have one resource per object instance (i.e. you are arguing that REST is on objects, my reading of the subject was that it was on classes). > > Mark. >
