{"id":675,"date":"2005-02-11T13:41:00","date_gmt":"2005-02-11T17:41:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/2005\/02\/11\/steve-maine-boils-the-rest-vs-ws-disagreement-down-to-its-essence\/"},"modified":"2005-02-11T13:41:00","modified_gmt":"2005-02-11T17:41:00","slug":"steve-maine-boils-the-rest-vs-ws-disagreement-down-to-its-essence","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2005\/02\/steve-maine-boils-the-rest-vs-ws-disagreement-down-to-its-essence\/","title":{"rendered":"Steve Maine boils the REST-vs-WS disagreement down to its essence"},"content":{"rendered":"

Update<\/em>; mea culpa, it was of course Steve’s post, not Tim’s. My apologies to both.\nOne of the disadvantages of reading blogs through Bloglines, since all the styling is lost.<\/p>\n\n

A thoroughly enjoyable\npost<\/a>\nfrom Steve. After a preamble on isomorphism, he presents an example SOAP message\nand asks;<\/p>\n\n

\nSo, an open question to the audience: are the SOAP messages I described above more “RPC style” or “document-oriented?” Are these services talking to each other, or stateful objects? Are you a good witch or a bad witch? To all these questions and others I answer: mu.\n<\/blockquote>\n\n

My answer is that they are RPC style. Let me explain further\nin response to his conclusion, which reads;<\/p>\n\n

\nAmazon.com’s e-commerce implementation is one of the most successful and highly touted REST API’s in existence today. The implications of the fact it’s also 100% structurally isomorphic to SOAP + WS-Addressing are left as an exercise to the reader.\n<\/blockquote>\n\n

Actually, it’s not isomorphic in that sense since the contract is very<\/em>\ndifferent in the REST and WS\/SOA cases (does that fall under “structurally\nisomorphic”? dunno).<\/p>\n\n

Let me start by tweaking Steve’s example to be what I would call a\n“document-oriented” style interaction;<\/p>\n\n

<S:Envelope xmlns:ht="http:\/\/schemas.hyperthink.net<\/a>\/" ... >\n   <S:Header>\n     ...\n    <wsa:To>http:\/\/hyperthink.net\/xml<\/wsa:To>\n\n    <wsa:MessageId>uuid:123...<\/wsa:MessageId>\n    <wsa:ReplyTo> ... <\/wsa:ReplyTo>\n    <ht:Service>CommerceService<\/ht:Service>\n\n    <ht:SubscriptionId>12ABC<\/ht:SubscriptionId>\n     ...\n   <\/S:Header>\n   <S:Body>\n     <ht:CartId>47<\/ht:CartId>\n\n     <ht:HMACToken>[blah]<\/ht:HMACToken>\n   <\/S:Body>\n<\/S:Envelope><\/pre>\n\n
Notice the difference?  wsa:Action has been removed.  So I could\nsubmit that message to a service, and it could return exactly the\nsame response as Steve’s example service does (though I’d remove\nthe wsa:Action from it too).<\/p>\n\n
Document in, document out.  Simple.<\/p>\n\n
Now, back to Steve’s Amazon URI based example.  My claim is\nthat the contract is different, just as the contract is different\nbetween Steve’s GetCart example and mine above.  Specifically, with the\nSOAP message, the request semantics are “GetCart”, and the response\nsemantics are “GetCart was successful”.  But in the URI example, the\nresponse semantics are “GET was successful” since the request semantics\nare GET.  In other words, with the URI, the client has zero visibility\ninto the semantics of the “GetCart” string (aka the URI is opaque), but\nin the SOAP message, it has full visibility.<\/p>\n\n
So rather than provide homework as Steve did 8-), I’ll ask\na single multiple choice question; what’s the operation in my\nSOAP message example above?  Is it;<\/p>\n\n