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.

Linking between I-D versions, within the IESG state machine, related documents, … Nicely done.
(link) [del.icio.us/distobj]

Just got back from a lovely dinner at Morimoto (grrr, flash), the restaurant of the famous Iron Chef Morimoto. I had the 2nd level Omakase tasting menu, which gave my tastebuds a workout through sweet, salty, bitter, and umami (no sour, AFAICT). There was a Chinese influence to at least a couple of the courses that I wasn’t expecting given his Japanese/Western-fusion reputation, but it was absolutely wonderful … except for the penultimate (prior to the dessert) course, sushi. The pieces were too small, which I can forgive, but it all tasted very “flat”, which I’m less forgiving about. I don’t expect that this was due to poor quality (the texture was wonderful, especially the toro) or preparation, but instead due to my palate being complete tuckered and unable to appreciate the delicate flavours of the fish. Perhaps I’m also not fully appreciating the structure of the meal, but I would have personally put the sushi as the second course, after the tuna tartar (and reduced it to three larger pieces).

Still, the previous six courses were to die for, and the restaurant was a site to see. Highly recommended, next time you’re in Philadelphia.

An interesting presentation from Sam upcoming at ETech. It’s titled ‘”Just” use HTTP’, and this is said about it;

Unlike other talks about newly emerging topics, Ruby’s centers around the reemergence of appreciation applications centered around the venerable HTTP protocol[sic]

Sam has this to say about it;

I’m planning on depressing a lot of people there. ;-)

Au contraire, my friend. 8-)

Update; as pointed out by Robert I think I totally misinterpreted the presentation. I can see now that it’s about the practical problems with HTTP/XML development. You can probably guess what I thought the main point of the talk would be. 8-)

James Tauber writes;

I think it would be fun being able to trace one's GMail Invite Lineage.

I got mine from Mark Baker.

Now if Mark reads this and says in his blog where he got his from and that person says on their blog (assuming they've got one) where they got theirs from...

So a call to all bloggers with GMail accounts: spread the meme!

I got mine from my old friend Nelson Minar, Google employee. I expect I know where he got his. 8-) Actually, let’s save a whole lotta time and just ask him for a dump of the invites database. 8-)

I met Paul in Honolulu at WWW2002 where he and his partner Chris Sukornyk were working on developing what turned out to be Semaview. Unfortunately things didn’t work out there, and Semaview recently ceased operations. But coincidentally, I happened to catch a pointer on the SWIG chump yesterday to an article written by Paul some time ago. It’s about Semantic Web Services, which immediately brought to mind an exchange we had a couple of years ago where I told him I thought it was great that he was planning to expose the functionality of their software, but suggested it be done over the Web rather than with Web services, which they did end up going with. Well lo-and-behold, but Paul has just resurfaced and written about his experience with Web services, and how he has now seen the value in the REST architectural style. He concludes;

Lesson learned. Keep it simple stupid.

Amen.

I’m going to be hitting some XML users group meetings in the North East US over the next couple of weeks, for my client Justsystem. If you’d like to meet with me to chat about XML, compound documents, or anything else Web-related for that matter, that’d be excellent.

My current schedule is;

• the Tri-XML meeting on Feb 8 in RTP
• the inaugural meeting of the Philadelphia XML Users Group on Feb 9
• the Washington Area SGML/XML Users Group meeting on Feb 16

I’ll keep my schedule up-to-date in this entry; there’s more to come.

Via Edd, a link to an interview with Stewart Butterfield. It’s a great interview all-round, but here’s a couple of points on topic for my weblog;

People who would be reluctant to provide metadata most of the time do so on Flickr because there’s a payoff for them. A) other people see their work–work is probably the wrong word because I don’t think most people see it as work in a serious artistic sense– but people see what they’re up to, see what they’re creating. And B) because they derive some pleasure from building value in the global collection.

I think this point is often missed by those who hold the “no cheap metadata” position. Turning “metadata” keywords into dereferencable URIs – as Flickr (among others) does – provides the means by which these “payoffs” that Stewart refers to, can be realized, cheaply. For me, it also helps drive home the point that one person’s metadata is another’s data, as this feedback loop is exactly the same one that exists when you publish any data behind a dereferencable URI. Taking it further, one might, for example, provide metadata for the Flickr metadata, which this is, if you squint a bit (not literally 8-). And to complete the loop and emphasize the point, one could easily republish many of these new images as new squared circles. Fractal!

As pointed out by Edd, Stewart also had this to say about Web services/REST;

I think we had one person inquire about using the SOAP version of the API. I don’t know if any apps were actually built. There is at least one application built on XML-RPC. But all the others–I don’t even know how many there are–are built on the REST API. It’s just so easy to develop that way; I think it’s foolish to do anything else.

Wow, but why?
(link) [del.icio.us/distobj]

“The Semantic Web accelerates the participation of machines in networked systems by providing them with a shared vocabulary, grammar, phrasebook and knowledge base.” – with all due respect to Graham, I think that approach will confuse folks more than info
(link) [del.icio.us/distobj]