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-)
This report about Google’s brand power reminds me of a discussion I had with a guy from Adobe at ETech who was pushing Apollo. I was trying to figure out why somebody would want to use it, and this guy’s response was “One word; branding”. Of course, he trotted out the expected example of Apple and iTunes and said that iTunes was more immersive and therefore provided Apple superior branding. Ok, fair enough. But obviously, as this report shows, Google didn’t require a fat client in order to build one of the world’s strongest brands.
Adobe’s ability to execute has been impressive, of course. But I can’t help but wonder if they wouldn’t be doing so much better had they simply innovated on top of the Web. I suppose that’s the easy way out, but it’s not nearly the most lucrative.
Dave Orchard on versioning;
The fundamental problem with a version # in a document is that it doesn’t provide for a given document to be valid under more than one version. What we really need is to be able to indicate a “space of versions” that a given document is valid under, whether that’s a list or regexp or whatever.
Amen. You know, just like a media type!
A quaint exchange
on the WebAPI WG mailing list;
>> Why not always uppercase method?
>
> That would upset the HTTP gods.
Ok. Fair enough.
I see that my work there is complete. 8-)
Eric Newcomer
succinctly
summarizes
my position on the history of Web vs. Web services;
But I believe your argument is that the industry went the wrong way from those early days by not recognizing that the uniform interface was part of the required adaptation of traditional middleware concepts to the Web, is that right?
Nicely done, Eric!
Personally, I like his previous attempt far, far better. Why go for loosey-goosey principles – few of which, AFAICT, are testable – when we all know that constraints define architectural styles? Come on Dave, give people the information they need to be able to say “That is SOA”, and “That isn’t”.
A couple of years ago, Dave pleaded for technical arguments
in the REST vs. SOA debate. I’d urge him now to do the same. As an example, perhaps he can explain, in technical terms, how he is able to defend a principle such as “Software should be as loosely coupled as possible to the interface” as well as service-specific interfaces. As I’ve pointed out, those two goals are at direct odds with each other because service specific interfaces fail to separate interface from implementation, and we all know that loose coupling is gained only by separating concerns.
Stu Charlton responds
to
my comment
(and Mark’s)
about how Pat Helland did things the hard way in discovering REST in a
recent paper
of his;
So, while the two Marks are suggesting Pat’s reached REST the hard way, I would suggest this is something he’s been saying for years, […]
That is the hard way! 8-O If Pat’s been unknowingly preaching REST constraints for years, then he’s done it from scratch. That’s a great personal accomplishment of course; I wish I were that smart. But wouldn’t it have been great if he had noticed that what he was talking about was being built out right under his nose for the past 15 years? 8-) I don’t fault him for that any more than I fault the bulk of the industry for also missing it (which is to say, a tiny bit 8-).
Anyhow, hopefully this paper can be the catalyst that helps push the industry towards a better understanding of the power and value of the Web. Of course, it also brings a new perspective to bear on the Web itself, from a seasoned distributed computing veteran, so that can only help Web proponents, perhaps motivating new Web based solutions. At the very least, they’ve got me thinking, which is always good 8-)
Eric, any chance we could get Pat to the
workshop?
… is the title of a new blog post by yours truly on my consultancy’s weblog.