Once again I’m happy to be a part of the program committee for the DOA conference. I’ve found the quality of papers there to always be quite high … yes, even some of the Web services ones often have something to contribute (I can forgive one wrong assumption 8-).
The CFP for DOA 2008 has just been posted. Please consider submitting.
I have to say, I’m with James in his response to Sam’s long bets;
To say, as Sam and Tim both do, that REST is important is like saying the fan in my laptop is “important”. There’s really nothing to discuss about it. RESTful services are fundamentally critical to the continued evolution of the Web. It just is. You just need to do things in a RESTful way. Period.
REST is just a starting point. What’s more important going forward is the framework which permits us to reason about REST extensions and other changes to the Web (or portions thereof).
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.
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.
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?
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!
I wanted to expand a little on my dismissal of Sanjiva’s argument that “The Web is necessarily human centric”.
Sanjiva, in his support for – and authorship of – WSDL, presumably wants to permit developers to publish their own service-specific interfaces, such as ones supporting methods like the canonical “getStockQuote”, or even “getRealtimeStockQuote”. And I’m certain he’d claim that these are very much machine-facing interfaces, since that’s supposed to be the whole point of Web services. So far so good?
So why is a system built around GET suddenly not machine facing? I’ve said before that the one thing that most distinguishes SOA and REST is the uniform interface of the latter; it says , in part, that the more general the operation, the more reusable the interface. In other words, using the example above, getStockQuote is more reusable than getRealtimeStockQuote. Moreover, GET is more reusable than getStockQuote.
By following that logic – that more general means more human-targetted – then one can only conclude that the methods most suited for machine-targetting will be the most specific ones. So never mind getRealtimeStockQuote, we’d need getRealtimeStockQuoteForGOOGonNASDAQ.
Of course, that’s silly. So is the argument that the Web is only for humans. I hope (hah! 8-) that this finally puts that argument to rest (pun intended).
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.