Hi, On 17 September 2010 15:21, Fabrizio Guglielmino <[email protected]> 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.
A delete action would have type "set". "get" is for retrieving information only, "set" is for any modification of a resource, including relocation and deletion. > 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. > No, it's not safe at all. The 'type' attribute has a specific set of values, and it should never be ignored. It would be quite sensible for a server to reject (and potentially close the stream) on receiving such a stanza. XMPP is extensible, but that doesn't mean you can redefine what's already there. Extension comes in the form of new elements and attributes in new namespaces, any of the XEPs give you an example of how this is done. > 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.... > Since you will have to define how "delete" and other actions are structured and include a custom payload anyway, I don't see why you wouldn't: <iq type="set"> <rest xmlns="http://example.com/rest"; action="delete"/> </iq> Regards, Matthew
