On Sep 17, 2010, at 08:21 , Fabrizio Guglielmino wrote: > Hi all, > > I'm trying to design a REST approach over XMPP, my idea is to transpose REST > normally used over HTTP to XMPP (a future RFC may be called REST over XMPP). > > The natural choice is for IQ stanza but types described in RFC are: > > - get > - set > - result > - error > > 'get' is perfect for reading a resource, 'set' may be used to POST or PUT (I > can accept to not distinguishing the two), but I'd like to have a 'delete' > type. > My question is: XMPP is extendible by nature but is possible to extend also > standard stanzas? Adding types to IQ should be safe also for clients using > XMPP standard (they simply ignore them) but I'm not sure this is acceptable > from XMPP standard point of view.
If the value for an attirbute or text content is an enumeration, adding to that enumeration is generally not acceptable. It's not as safe as you may think, since the stanza type isn't usually ignored. This is especially true for <iq/>, where a result/error is expected to any get/set request, and entities MUST respond to <iq/> requests type=get|set). Adding another type there could lead to undesirable or unexpected behavior; getting back an <iq type='error'/> in response to an <iq type='delete'/>, or possibly having the connection dropped out from under the client. > > Obviously I can use standard type moving operation identifier (get, set, > delete...) in custom elements inside them but I think a more "purist" > approach can be better.... It depends on one's idea of "purist" (-: We've done the former, either as an attribute on the payload element or as the payload element's name itself. - m&m
