[Standards] Proposed XMPP Extension: REST with XMPP

Lance Stout lancestout at gmail.com
Wed May 27 06:51:10 UTC 2015


/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.


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:



Let Resource be represented by a node named "/the/resource".


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>


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>



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.



- Lance


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4115 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150527/a62eca13/attachment.bin>


More information about the Standards mailing list