DevHawk (Harry Pierson) raised today a question I was toying with myself for a while now - if REST is an architectural style can it exist without the specific technologies that define it today. Or as Harry put it :

1. REST is a an "architectural style for distributed hypermedia systems".
2. REST "has been used to guide the design and development" of HTTP and URI.
3. Therefore REST as an architectural style is independent of HTTP and URI.
4. Yet, I get the feeling that the REST community would consider a solution that uses the REST architectural style but not HTTP and/or URI as "not RESTful".

What I had in mind for example is to use messaging where the equivalent of the URI would be a topic hierarchy.
Topic hierarchy allows you to have a unique "URI" for each resource.
The next thing we need to take care of are the PUT, GET, POST and DELETE verbs - we can do that by making the verbs part of the message headers.
As an aside I'll also say that  if we try to think about it as an architectural constraint then we don't necessarily have to use these verbs, a more general rule would say that the verbs are uniform and well known rather than specific ones
The rest (no pun intended) of the concerns, like specifying related states etc. can be dealt with making conventions on the message formats
Is that still REST?! I wonder...

In any event, what worries me the most in regard to REST is the religious manner that some people seem to treat it. By the way that is the same phenomena we see with some of the Agile folks. As for me? - Well, I don't really care if I fit that label or the other. I am just payed to deliver working  and viable software :), but hey, that's another discussion.