On Mon, Mar 31, 2008 at 1:29 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > > > > Let's try to RESTify it in order to have a more general solution: > > What is the particular benefit here of having a RESTful interface?
An exercise, since the XEP was referencing REST ;) Jokes apart, REST is paradigm that clearly separates the roles in a distributed application, trying to leave out from the transport any aspect that is application dependent, such as session handling. I'm not a RESTologist, or a REST worshiper, but there is good common sense in it, and when designing a protocol it is wise to give a look to these principles. An example: ad hoc commands handle sessions, but just one a particular type of session; they have verbs (the action), but these verbs haven't an extensible semantics they just allow to perform an operation in steps, forward and backward. In order to be more extensible (and RESTful) the session handling mechanism should be left to the application, and the verbs should be defined by the application itself. In this way we can really carry anything between two endpoints and support any future extension. > In particular, do you think that we need to reference each action via a > URI? Such as: > > xmpp:compute.example.com?io;node=foo;action=get;data=schema This is mixing state transfer data with the resource (in rest terminology), let's just reference the resource (i.e. the XMPP node) with an URI, and put data in the payload. This simplifies the work of the application, since the XMPP infrastructure should just route the "bag" containing the operation to the correct node, and then the application associated to the node can interpret it. An example: <command node="xmpp:compute.example.com/resource;node=foo" action="get"><!-- query --></command> Also in web application there is a bit of confusion about this, since in HTML forms you can send data either with a GET or POST. In REST indeed GET and POST are well separate actions: the former just does a query, without modifying the resource, and you can send some parameters of the query; the latter is for setting some property of the resource, thus modifing it. > > - retrieving the data scheme is an operation on a particular node (a > > GET), so we don't need a particular action, just get it from the > > correct node, e.g. GET /nodename/schemata > > > > <iq from="..." to="..." id="..." type="set"> > > I think you meant type='get' :) I was wandering about it, "get" means that we are just querying the node, while "set" that we may modify it. Since in this case XMPP is just a transport that should be as blind as possible concerning the carried data, I'd leaving always "set", meaning the we are placing an operation on a node. Which operation is then specified inside the command. > > > <rest node="/nodename/schemata" action="get" xmlns="api:rest"/> > > </iq> > > It might be good to separately specify the node and the data type (in > this case, the schema). It's a more general problem of node hierarchy; for extensibility imho there shouldn't be too much semantics associated to the node. In the web world they have a simple mechanism for just saying that the "/nodename/schemata" resource depends in some way from "/nodename", amd that is the use of paths; which dependency is again left to the application. Any simple xml scheme for this is welcome, I just can't think of any in this moment (the collection / leaf nodes of pubsub aren't suitable I think). bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
