It’s nice to see Pat Helland join the REST/SOA conversation.

His first post is in a rather quisical, loose style that I hadn’t seen before, but that’s ok, I think I get what he’s talking about. The point seems to be summed up here;

Is the purchase-order (or even the line-item) a noun or a verb? I would argue is it syntactically a noun but semantically a verb.

Hmm. I’m quite certain it’s pure noun. If it were a verb, then it would only have a single-purpose – to order something – and wouldn’t be able to be archived, printed, translated, etc… which it clearly can. Obviously a message can only have one authoritative application-level verb, and if you’re using HTTP, then the request method is it.

I was chatting with a friend of mine who lives in London, and he happened to mention he was spending more time in Canada this year than he ever has. In addition to attending a conference, he was also planning to spend some vacation time here. “Where abouts?” I asked. Prince Edward Island. “Hey, that’s where we’re vacationing this year!” I said. “When?” We’re there the same week.

“So where are you staying?”

It turns out we’re in cottages separated by no more than 300 metres, in the smallest, least touristy county on the island. It’s a small island, but not that small.

Freaky.

So I had a quick look at Google Gears this morning. Unlike some, I do most definitely see value in supporting disconnected scenarios, not because I don’t see pervasive wired and wireless networks being the rule in the not-too-distant future – I do – but because I understand that networks are unreliable. That said, I do have some concerns about how Gears was put together.

My primary concern is that I’ve always felt that supporting offline use in existing browsers required more innovation of implementation rather than interface, whereas Gears is all about interface. What I mean by that is that I believe that a better, more easily deployable and usable solution would be for Mozilla itself to tweak the implementations of its HTTP stack, cache, and XMLHttpRequest object. Instead, Gears gives us new interfaces like LocalServer, which developers are supposed to use to check for valid cached representations before hitting up XHR: something XHR could very well do itself, largely transparently (I expect – haven’t considered all the backwards-compatibility issues).

Now, Gears could very well be something that was deployed for its ability to enable features today, because Google didn’t want to have to wait for HTML 5 (and its equivalent of client-side storage) to be deployed. And from that perspective it’s great (though requiring a plugin is a bit of a pain). I just hope that the Gears folks are talking with Hixie and Mozilla about where to draw the line here.

This made my day. 8-)

I’m kinda busy with a bunch of things on my plate, but felt I had to chime in on the latest calls for a RESTful description language ala WADL.

Aristotle’s response struck a chord;

[…] there isn’t much to describe; there aren’t any methods or signatures thereof to document, since access to resources is uniform and governed by the verbs defined in RFC 2616 (in the case of HTTP, anyway)

Right-o, though it might be helpful to rephrase that last bit as “since access to resources is through the *same* uniform interface”, because that’s the whole point of REST: all services expose the same interface. This is what provides the majority of its loose coupling, and is the principle differentiator from RPC.

So if you’re writing (or generating) contract/interface-level code which can’t late-bind to all resources, everywhere, you’re not doing REST (10 kudos to whomever identifies the specific constraint being violated).

Cut the cord already! RPC is dead. You’re not in Kansas anymore.

The details are on my other weblog.

I made a comment on Pete Lacey’s latest in the “RIA” discussion that I wanted to reiterate here;

how is that different than the bad old days when a site was developed for one particular browser?

So that whole “contract thang” has popped up again in the echo chamber. I’m going to pick on Steve Jones a little (more 8-), specifically something he says in his latest piece;

Where I do disagree though is whether this is a good or a bad thing to have these camps. Now I’m clearly biased as I’m on the contract side […]

Hold it! Let’s make sure we’re having the right conversation here. It’s not “pro contract” vs. “anti contract”, it’s simply “many contracts” vs “one contract”.

Resume!

I’m absolutely thrilled that Tim has finally grokked REST. AFAIK, he’s the first die-hard Web services type with a strong public persona to realize REST’s (and the Web’s, of course) benefits over WS/SOA/RPC. Bravo, Tim!

I’ve long thought that what was needed in this discussion was new perspectives on the relationship between REST and WS/RPC/etc… that would permit the message to reach more people. Tim’s ably doing his part along those lines with his followup posts. I would never have thought to describe things this way.

So, who’s next?

I’ve spent some time over the past couple of months helping Microsoft with RESTful issues for two (soon to be three, I hope) different groups there. One of those is the WCF team, and Omri has just reported on some of it. I’m not sure how much of my input (if any) made it into that release, or if it’s all set for the next release, but there you have it; WCF does REST.

It was quite enjoyable to sit around the table (conference room and sushi table alike!) with Don and Steve in the context of trying to answer the question “How can Microsoft best support RESTful service developers?”, and not have to dwell much on the SOA/WS-vs-REST thing. Lots of love all round. 8-)

I’ll point to the other projects as soon as I know they’ve gone public.

Update; if it wasn’t clear, this was a consulting arrangement through my company, Coactus.

Update 2; the second project has been announced. Here’s more; doesn’t that XML just scream “Yaron”? 8-)