I've been trying to grok REST of late (yes, I've even read Roy Fielding's dissertation). The concept is much-hyped but, to my mind, vague. Or, at the least, I don't (yet) see how it applies to the wonderful world of Jabber. For instance, in the comments to a post by Adam Bosworth from 2003, RESTafarian Mark Baker said:
REST says a few things, but one of them is not that HTTP is the only protocol to use. What it does say is that the use of other protocols is limited to HTTP-like semantics. What that means, roughly, is that you have to, in effect or in actuality, use an HTTP proxy in front of all other services. For example, this is how browsers use FTP.
Well, it pretty much all boils down to the same thing, doesn't it? I mean, in XMPP we have some HTTP-like (i.e., request-response semantics) semantics, but they don't happen through an HTTP proxy; instead, they happen natively in our protocol (via the stanza). Does that make XMPP IQs unRESTful?
And what about semantics other than those familiar from HTTP? In XMPP we have three kinds of semantics:
It seems downright silly to say that it's a good thing to limit the use of other protocols to HTTP-like semantics, given that push semantics have launched not one but two killer apps -- email and IM.
And presence too opens up a whole world of new applications (it forms the bedrock for IM). Presence is one form of pubsub semantics, but not the only one, which is why in the XMPP community we abstracted from our more basic presence functionality to define a generic pubsub protocol. And pubsub semantics seem to be of interest even to folks in the HTTP community -- heck, there are even proposals to do pubsub over HTTP by defining some new HTTP verbs (if those are standardized, are they automatically included in the universe of "HTTP-like semantics"?).
By "RESTful" some folks seem to mean "it's available at a URI". Well, that's nice, but is it everything? Sure, we too have an XMPP URI scheme, but we don't typically use it to express availability of all resources. Does that make XMPP unRESTful?
AFAICS, Adam Bosworth's five questions are still apropos (especially since he explicitly mentions Jabber as a desirable transport protocol). I paraphrase them as follows:
How does REST enable the sender of the message to know reliably that the receiver has received it?
(In XMPP we do this via IQs if you're comfortable with receiving errors on failure but nothing on success, or via advanced message processing if you need greater reliability.)
How does REST correlate responses with sent messages in the absence of HTTP cookies?
(In XMPP we do this via the 'id' attribute on IQ and message stanzas.)
How does REST provide transparent service descriptions in the absence of WSDL?
(In XMPP we have service discovery and we endeavor to define our protocols clearly enough that the programmer's job is made easy.)
How does REST push out context-specific data in real time without requiring the client to maintain a large amount of state?
(In XMPP we can do this with our pubsub extension, although programmers haven't yet tapped into its full power.)
How does REST enable an entity to subscribe to events and receive unsolicted messages when someone publishes something of interest?
(Here again in XMPP we do this with our pubsub extension.)
It strikes me that XMPP satisfies quite a few of the REST principles. It's client-server and stateless (no cookies here) and layered (data is separated from presentation). It has a small number of well-defined operations (IQ get and set, message, presence, pubsub publish and subscribe, data forms of type form and submit) and content types (the various XMPP extension "payloads"). Etc. But we don't make "resources" the center of our universe (I guess you'd say that entities and messages are primary in XMPP), we don't use URIs to identify all "resources", and cacheability is not critically important in our world.
So I don't know that the Jabberites will ever be good RESTafarians. But given that REST seems to be something approaching a religion rather than a set of practical, helpful guidelines for building interesting services, I also don't know that it really matters all that much. :-)