Chris responds to an earlier comment of mine.
My point remains that HTTP is not suited to extension of its methods because it requires centralized administration of the method names. You can’t simply make up a new method like MONITOR and deploy it unless you go through the IETF to revise the HTTP specification. Unless you do, then there’s no way that anyone could tell the difference between Mark’s MONITOR method and mine (should I devise one) and yet they might be very different animals.
His point about decentralized method definition is very well taken; HTTP does not permit method names to be URIs. PEP attempted to remedy this, but was never deployed.
But in order to use MONITOR, the HTTP spec doesn’t need revision. There are a multitude of HTTP extensions which are defined as standalone extensions which required no revision of HTTP itself. Consider WebDAV. And as Dave Orchard noted, HTTP is rife with extensibility points; this is no accident, because HTTP was explicitly designed to be extended. Which brings us to this comment;
HTTP wasn’t designed to support pubsub. Just because some sharp people can take the protocol and tweak it here and there to enable pubsub doesn’t change that fact.
HTTP was not designed to support pub/sub, but so? Was SOAP? Nope. But that doesn’t prevent one from using it that way. What’s important is that it wasn’t designed in such a way that prevented (even by being merely a “poor fit”) its use for pub/sub, and IMO, neither HTTP nor SOAP were. HTTP was designed for document transfer, and pub/sub fits there perfectly.
Chris then asks a very good mod_pubsub question;
However, all that aside, I am curious about something else related to mod_pubsub. Sure, it makes use of HTTP GET as well as POST, but are GET and POST really the methods? I mean really… how is this any different than the way in which SOAP uses HTTP POST? do_method?
This is largely what I was referring to when I said “well, parts sure are, but the bulk of it?” in reference to mod_pubsub and hackery. The client portion of mod_pubsub – the Javascript Web server and library – had to resort to lowest common denominator; AIUI, they couldn’t present access to HTTP internals to developers. AFAIK, that’s why “route” is a parameter rather than a new method. It’s actually semantically quite close to WebDAV’s COPY method, both in that it is essentially a copy action, but also that it’s an “interaction at a distance”, i.e. that two URIs are used as arguments, rather than just one which would have required the data being routed to flow to the client. But doing this RESTfully, I could easily imagine a ROUTE method.
This is different to a typical Web services approach (I won’t say “SOAP approach”, because SOAP can be used in so many ways), due to two reasons IMO; first, the semantics being tunneled are uniform, and second, they’re tunneled because there was no other way to do it. In my observation, Web services developers use tunneling primarily because they don’t know how to solve their problems without tunneling, and because they’ve been lead to believe that “protocol independence” is a feature rather than a bug.
no comment until now