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
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-)
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]
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.
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
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
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
of the uniform interface
- Atom rejecting
calls to define a SOAP API
and instead going with a
saying that 85% of their “Web services” traffic is
via the RESTful interface
- Jim Webber and
supporting a uniform document submission semantic, dubbed
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]