Web Things, by Mark Baker

Worst weblog title ever. 8-O Speedy recovery, Rich.
(link) [Mark Baker’s Bookmarks]

Big, huge, massive +1
(link) [Mark Baker’s Bookmarks]

Savas posted a good state-of-the-conversation post upon his return, so I’ll respond to it. I still hope to respond to his earlier response to a question of mine, in what will likely end up being a mini treatise on state and state references. But that’ll have to wait.

I am now thinking that it is time to explore whether it would be possible to take the “processThis” idea to a next level. First, we really need to change the name; perhaps something like “processDocument” or “processMessage”; I like the latter better.

I could live with either, but I’d prefer “processDocument” since it’s more specific. “processMessage” could include the processing of a document (i.e. a chunk of state), or the processing of an explicit request for some action to occur. To my mind, “processDocument” suggests the former, which is what we all seem to want; state transfer.

Then, we need to demonstrate that we are not that far really from REST and, in fact, the REST approach can be seen as a subset of our model where the protocol verbs are effectively modelled as a submission of documents to the “processMessage” abstract operation.

Yes, you really aren’t very far from REST. Your architectural style seems to be state transfer based, which is awesome. I say “seems”, because Jim’s response to Matt Garland’s suggestion for how queries should be done suggested that he supported a non-state-transfer approach to querying. Which brings us to …

This last observation answers Mark’s point about the semantics of GET in this post. The semantics of GET can be captured through an appropriate SOAP message. An HTTP request-response pattern can also be described as a message exchange pattern in which the receiver of the request will send a message to the “processMessage” operation of the sender.

I think this is an absolutely critical point to the understanding of REST, or at least how it relates to the style you promote. But I think you’ve got it wrong there Savas, on two counts.

Second point first; I think the comparison between HTTP request/response and “processMessage” is incorrect; the comparison should be between HTTP POST and “processMessage”. That is, if you take away all the HTTP operations except POST, what you’ve got remaining is an application protocol with a single explicit (though it could just as well be implicit) operation which is semantically identical to a state-transfer semantic, which I understand processWhatever to be.

Second, though related, I’m certain that query semantics cannot be captured by an “appropriate SOAP message”. Consider that for any SOAP query document you can construct, I can present a SOAP service which simply adds that document to a queue (just as an example), and returns a success bit (e.g. an HTTP 204 message) with no other information. What this means then, is that a service which does respond to the query, is actually presenting a different abstraction than the one which places it in the queue. In other words, the query service isn’t using “processMessage” semantics. To query, you need a query semantic. And if you’ve got a uniform document submission semantic in processMessage, then why not a uniform query semantic? In my view, that should be the “next level” we take; it need not be full REST, of course, just an, IMO, superior style than what’s there now.

I’ll leave it at that for now, I think. The state issue needs to be addressed as I mentioned, but I think it can be decoupled from this argument.

P.S. enough of the love-in, ok guys? I’ve got a rep to maintain. 8-)

And so the platform battle begins; can Yahoo extend their services as quickly and cheaply as Google?
(link) [Mark Baker’s Bookmarks]

Oops, sorry for not participating but it seems that Yahoo had me pegged as a “soft bouncer”, and moreover, my notice of that change in status got caught in my spam folder. Doh!
(link) [Mark Baker’s Bookmarks]

This makes some sense, but ouch, they should have gone to the Atom community first.
(link) [Mark Baker’s Bookmarks]

Jim Webber’s flattered that I included he and Savas in my list of highlights. No problem, you guys earned it. AFAIK, you two were the first self-described Web services proponents to be able to put the CORBA-like legacy completely behind you and go for a pure document exchange model; none of this hybrid document/RPC crappola.

He adds;

Now if only I could convince him to decouple the Web from Web Services. There’s a whole Internet to embrace outside of HTTP :-P

Heh, very true, there is a lot more to the Internet and Web than just HTTP. But, not so much more that most (not all) of it can’t reasonably be used via an HTTP proxy, or in an HTTP-like manner. Just think about how many other systems have been Web-ified; email addresses use mailto:, FTP, though not used nearly as much since the Web came along, is hardly ever used without an ftp: URI.

(Jim and I are having an exchange off-line which suggests he was thinking in this direction; kudos!)

So I was thinking last night about how far – or not – we’d come in the whole “Web vs. Web services” debates. In one respect we’ve come a long way; you hardly ever hear the argument that “the Web requires humans!”. Many (but still not all) people remain indifferent about that; that the Web may or may not be usable for this, but it’s moot anyhow, because the “World isn’t going that way”. But that’s still pretty good, as it shifts the discussion into the more concrete and less subjective realm of software architecture, allowing us to use reasonably well understood means of evaluating and comparing architectures for suitability to a particular problem domain.

But on the other hand, the Web still doesn’t get the respect it deserves from a lot of folk as a serious distributed computing platform. I’ve just been reviewing some papers for Middleware 2004, and some of them talk about a variety of distributed computing platforms, yet all fail to mention the Web as a peer.

There’s been a lot of low points, obviously, over the past four or five years, but a few highlights too. Some of the latter include;

• the XML Protocol WG agreeing – after much lobbying from Henrik and myself – to use HTTP error codes for the transfer of SOAP faults
• the TAG finding on When To Use GET, though I haven’t seen a Web service that uses it that way yet
• Roy Fielding‘s defense of the uniform interface
• Atom rejecting calls to define a SOAP API and instead going with a RESTful design
• Amazon saying that 85% of their “Web services” traffic is via the RESTful interface
• Jim Webber and Savas Parastatidis supporting a uniform document submission semantic, dubbed processThis

Now, with Tim Bray joining the ranks of the WS-Disenfranchised (albeit for slightly different reasons than myself), the future’s looking even brighter. Onward!

Ick, the JSF “form” tag only supports HTTP POST, not GET. Repeat after me, “URIs and GET are goodness”. It’s easy to work around (write your own HTML or a new tag), but still …
(link) [Mark Baker’s Bookmarks]

Dumb, dumb, dumb. Atom is cool, but it’s not backwards compatible with RSS (though an RDF version would be, nudge nudge).
(link) [Mark Baker’s Bookmarks]