{"id":376,"date":"2004-05-18T21:14:00","date_gmt":"2004-05-19T01:14:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/?p=370"},"modified":"2004-05-18T21:14:00","modified_gmt":"2004-05-19T01:14:00","slug":"processthis-and-other-uniform-semantics","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2004\/05\/processthis-and-other-uniform-semantics\/","title":{"rendered":""processThis" and other uniform semantics"},"content":{"rendered":"

Savas posted a good\nstate-of-the-conversation post<\/a> upon his return,\nso I’ll respond to it. I still hope to respond to his\nearlier response to a question of mine<\/a>,\nin what will likely end up being a mini treatise on state and\nstate references. But that’ll have to wait.<\/p>\n\n

\nI 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.\n<\/blockquote>\n\n

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

\nThen, 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.\n<\/blockquote>\n\n

Yes, you really aren’t very far from REST. Your architectural style\nseems<\/em> to be state transfer based, which is awesome. I say “seems”,\nbecause Jim’s response to Matt Garland’s\nsuggestion for\nhow queries should be done<\/a> suggested that he supported a non-state-transfer\napproach to querying. Which brings us to …<\/p>\n\n

\nThis 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.\n<\/blockquote>\n\n

I think this is an absolutely critical point to the understanding of REST,\nor at least how it relates to the style you promote. But I think you’ve got it\nwrong there Savas, on two counts.<\/p>\n\n

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

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

I’ll leave it at that for now, I think. The state issue needs to be\naddressed as I mentioned, but I think it can be decoupled from this argument.<\/p>\n\n

P.S. enough of the love-in, ok guys? I’ve got a rep to maintain. 8-)<\/p>","protected":false},"excerpt":{"rendered":"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 […]","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-376","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-soap"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/376","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/comments?post=376"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/376\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=376"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=376"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=376"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}