On 27 May 2015 at 07:51, Lance Stout <lancest...@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.
