[Standards] Proposed XMPP Extension: REST with XMPP

Dave Cridland dave at cridland.net
Wed May 27 15:13:26 UTC 2015


On 27 May 2015 at 07:51, Lance Stout <lancestout at gmail.com> wrote:

> /Puts on Council hat
>
> I'm -1 on this for now because this really needs some more discussion on
> the list as this duplicates quite a bit.
>
>
Likewise; my comments are unanswered.


>
> Technical nitpicks for proposal as is:
>
> - The 'jabber:iq:rest' name should not be used. The 'urn:xmpp:xml-rest'
> namespace could be used instead.
> - If the <resource /> element can only have the child <method />, why not
> use <resource method="X" />, or <method name="X" path="/foo" />?
> - An example showing retrieving the value of a resource would be useful.
>
>
>
>
> Given that XMPP nodes can represent resource paths, the proposal reduces
> to providing a new call/response mechanism that places the action name in
> an attribute value of a generic element (<iq><resource><method
> name="ACTION" /></resource></iq>) instead of an action-specific namespaced
> IQ child element (<iq><ACTION xmlns='ACTION-NS' /></iq>).
>
> Likewise, a new form description schema is provided instead of using
> Dataforms. I do see that there are some special types introduced, but those
> few special cases could be added as an extension to Dataforms instead of a
> full replacement.
>
> A discovery method is introduced for finding methods that a resource
> supports, but that is already provided by Disco#info features. Of course,
> Disco does not itself provide parameter definitions, but we traditionally
> do that by using an IQ-GET to retrieve an empty data form, followed by an
> IQ-SET to apply the data form.
>
>
> If the goal is to provide easy mappings for CRUD behaviour, then consider
> this straw man:
>
>
>
(XEP-0050 straw-man also added)


>
> Let Resource be represented by a node named "/the/resource".
>
>
It's not totally clear what these resources represent, but I'm going to
push back very hard on introducing a path-like semantic.


>
> To find methods supported by the Resource:
>
> <iq type='get'><query xmlns='http://jabber.org/protocol/disco#info'
> node='/the/resource' /></iq>
> <iq type='result'>
>   <query xmlns='http://jabber.org/protocol/disco#info'
> node='/the/resource'>
>     ...
>     <feature var="urn:example:xmpp:rest:get" />
>     <feature var="urn:example:xmpp:rest:put" />
>     <feature var="urn:example:xmpp:rest:post" />
>     <feature var="urn:example:xmpp:rest:delete" />
>     ...
>   </query>
> </iq>
>
>
I'm thinking that well-known command names would work just as well.

An interesting point here is that XEP-0050 operates at the Jid level, and
not the Node level - this is problematic with its potential operation with
PubSub as well, so that would be a problem worth solving.


>
> Discovering parameters of the "post" method for the Resource:
>
> <iq type='get'><post xmlns='urn:example:xmpp:rest' node='/the/resource'
> /></iq>
> <iq type='result'>
>   <post xmlns='urn:example:xmpp:rest' node='/the/resource'>
>     <x xmlns='jabber:x:data'>...</x>
>   </post>
> </iq>
>
>
> Performing a "post" to the Resource:
> <iq type='set'>
>   <post xmlns='urn:example:xmpp:rest' node='/the/resource'>
>     <x xmlns='jabber:x:data'>...</x>
>   </post>
> </iq>
> <iq type='result'>...</iq>
>
>
>
The above two are identical to Ad-Hoc.


>
> Such an approach would still need refining, but it would fit in better
> with existing XEPs without creating a parallel track of extensions for new
> method types.
>
>
Another approach might be to allow the definition of XEP-0050 command
side-effects to be published... That would allow REST-like semantics to be
built, but also allow multiple create commands, etc, to be made -
eliminating the somewhat clunky REST API semantics of having to have the
method name as part of the payload of a "super method". Much as it amuses
me to have an object inheritance hierarchy of polymorphic messages, it's
pretty ugly.

Knowing, on the other hand, that a particular XEP-0050 command is
idempotent, or will change a node, or will create one, and so on, seems
useful.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150527/fd730eb7/attachment.html>


More information about the Standards mailing list