Web Things, by Mark Baker

Update; mea culpa, it was of course Steve’s post, not Tim’s. My apologies to both. One of the disadvantages of reading blogs through Bloglines, since all the styling is lost.

A thoroughly enjoyable post from Steve. After a preamble on isomorphism, he presents an example SOAP message and asks;

So, 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.

My answer is that they are RPC style. Let me explain further in response to his conclusion, which reads;

Amazon.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.

Actually, it’s not isomorphic in that sense since the contract is very different in the REST and WS/SOA cases (does that fall under “structurally isomorphic”? dunno).

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

<S:Envelope xmlns:ht="http://schemas.hyperthink.net/" ... >
   <S:Header>
     ...
    <wsa:To>http://hyperthink.net/xml</wsa:To>

    <wsa:MessageId>uuid:123...</wsa:MessageId>
    <wsa:ReplyTo> ... </wsa:ReplyTo>
    <ht:Service>CommerceService</ht:Service>

    <ht:SubscriptionId>12ABC</ht:SubscriptionId>
     ...
   </S:Header>
   <S:Body>
     <ht:CartId>47</ht:CartId>

     <ht:HMACToken>[blah]</ht:HMACToken>
   </S:Body>
</S:Envelope>

Notice the difference? wsa:Action has been removed. So I could submit that message to a service, and it could return exactly the same response as Steve’s example service does (though I’d remove the wsa:Action from it too).

Document in, document out. Simple.

Now, back to Steve’s Amazon URI based example. My claim is that the contract is different, just as the contract is different between Steve’s GetCart example and mine above. Specifically, with the SOAP message, the request semantics are “GetCart”, and the response semantics are “GetCart was successful”. But in the URI example, the response semantics are “GET was successful” since the request semantics are GET. In other words, with the URI, the client has zero visibility into the semantics of the “GetCart” string (aka the URI is opaque), but in the SOAP message, it has full visibility.

So rather than provide homework as Steve did 8-), I’ll ask a single multiple choice question; what’s the operation in my SOAP message example above? Is it;

• A. GetCart
• B. ProcessMessage
• C. POST
• D. B and C
• E. There is no operation

Hint; there’s always an operation, since something has to succeed or fail.