[Standards] [API] Proposed XMPP Extension: IO DATA
fabio.forno at gmail.com
Mon Mar 31 09:26:09 UTC 2008
On Mon, Mar 31, 2008 at 1:29 AM, Peter Saint-Andre <stpeter at stpeter.im> 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
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:
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
> > <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).
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com
More information about the Standards