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-)
no comment until now