Seems like folks are excited about Roy’s upcoming ApacheCon talk.
The title – A little REST and Relaxation – is the same title as the keynote (video) he gave at Jazoon this summer, so I assume it’ll be similar if not the same (hopefully a bit longer, as Roy’s obviously rushed for time in the video).
I liked the talk a lot, as you might have guessed. I particularly liked how Roy echoed some of the things I’ve said the past few years nearly word for word. For example, he talked about how SOA was effectively the null architectural style. He also talked about the pros and cons of relaxing REST’s constraints, including the very high cost of relaxing the uniform interface constraint (something I’ve pointed out many times), but the relatively low cost of relaxing client/server.
Update; Pete reminds me that Roy used the Lego analogy, which I’ve used before too.
Sanjiva uses the wrong word when pointing out distributed systems development is hard.
I thought that RESTafarians used to say that WS-* was all too complicated and REST is so easy and beautiful. ;-).
No RESTafarian I know ever said REST development (in general) was easy, only that it was simple, where “simple” refers both to the architectural property of simplicity induced by some of REST’s constraints as well as to the general notion that using any reasonably constraining architectural style reduces the number of decisions a user of that style has to make. “Easy” would mean that this second notion of “simple” implied that all the remaining choices were trivial, which is clearly not the case. Yes, distributed systems are hard. But their styles needn’t be complex.
I’ll give him “beautiful” though 8-)
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).
Eric Roch comments on a post from Anne Manes from a couple of months ago, and seems to be under some misconceptions about REST.
Misconception: “Stateless” means no persistent data
To be RESTful state must be transferred from the server with each interaction. This can be problematic for many applications – can you trust the other party to maintain state from a security and transactional perspective? For example, if the application keeps a running calculation of product costs – is it okay to transfer the calculated costs and trust the cost when it comes back in the state transfer? Some costing applications are complex and recalculating costs every time the user responses just to be RESTful might not make sense.
This is a very common misconception for REST newbies. What Eric’s doing there is confusing application state and resource state. REST’s stateless constraint only requires that application state be maintained on the client. It places no constraints on resource state, such as Eric’s “running total” above.
Obviously REST wouldn’t be very interesting if it were unable to support persistent data.
Misconception: REST doesn’t support dynamically generated content
Also, since you need unique URIs for caching, you cannot have one URI for a dynamically built page and be RESTful.
That one, I’ve never heard before 8-) It’s not true of course, because dereferencing a URI one day can return a different representation than it does the next day. That’s pretty fundamental to REST.
No wonder Eric’s been such a strong Web services supporter if he thinks REST can’t support changing data, nor persistent state! 8-O
Misconception: HTTP(S) can’t do what I need, so I can’t use REST
Then there are of course the constraints of the HTTP(S) transport [...]
Sure, but they have nothing to do with REST. Just because HTTP(S) can’t address your needs, it doesn’t mean you have to abandon REST. You might consider an HTTP extension if you would otherwise be able to use it, but if HTTP is totally out of the question and you need a new protocol, you can still use REST’s constraints in designing that protocol. I’ve done that myself in fact, and designed a UDP based transfer protocol for use over satellite links.
Elias has noticed that my blog has fallen silent recently, and suggests that REST’s victory over WS-* has something to do with it.
I haven’t had much contract work the past few weeks, but have been helping a couple of startups. But the main reason I don’t blog is that my curmudgeonly style really only works when I’m the lone voice, arguing for the unpopular-but-superior solution. Now that the arguments I’ve been making for the past seven or so years are finally being recognized as superior, I’m sure I’d come off as just plain mean if I were to go after anybody who said that they were sticking by WS-* (something about kicking a horse when it’s down).
What comes next for me and this weblog then?
Something I considered doing a couple of years ago was a regular “Ask Mark” piece, where I’d publish one of the many REST/Web questions I get via email. I’d been answering those privately for years, but perhaps I could now do so on condition that I can publish them (though few are really interesting).
Another thought was covering REST/Web esoterica. There’s an abundance of interesting topics to cover on the fringes of REST and the Web. Yet another was a retrospective of some of the more heated battles over the past years, on weblogs and mailing lists.
Let me know what you’d like to see me cover.
I’ve said it before, but apparently not enough as David Chappel chimes in with this;
A RESTful approach is a natural for data-oriented applications that focus on create/read/update/delete scenarios.
He’ll get no argument from me that REST is good for data-oriented applications, but saying that it’s only good for the subset that fit the CRUD model is wrong. It’s wrong because CRUD doesn’t have an equivalent for HTTP POST. Once you incorporate POST into your repertoire, then you can do all kinds of interesting things like, say, ordering stuff.
Perhaps David – or anybody else – could point me towards a data oriented application which can’t fit (well) into such a model (not REST, just the uniform interface part).
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’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.