Is Statelessness Required? The universe will not end in an ontological segfault if you violate statelessness. Instead, you will give up a lot of scalability potential, and you will hide state where your clients can't get at it, which will annoy them. So why do it? Maybe because you're using a framework that makes it really easy to write programs that violate statelessness, and then tries complicated tricks to get scalability back, because that's the way web frameworks have been written for ten years.
We took a pretty hard anti-cookie line in RWS (pages 252-253), but we made it clear that cookies themselves are not the problem. Cookies, like links, are a way of serving application state. They have one big RESTfulness problem but it's moot because nobody follows the cookie standard that slavishly. The real problem is the session IDs that go into those cookies.
A session ID is a key into a big chunk of state kept invisibly on the server. That's what causes the problems. It's just as wrong to serve that session ID as a query variable in a link as it is to serve it in a cookie. You need to turn the hidden state into application state by incorporating it into links and forms, or you need to turn it into resource state by exposing it as part of your web service and letting clients manipulate it directly.
Is Being Message-Centric Good Enough? I say yes. I'm young enough that the Web is the first distributed programming environment I ever used. I've never felt like I was missing something that justified switching to a competitor. The more I've learned about its design the more impressed I've been. When something better comes along, I predict it will look more like the Web than it will look like DCOM or CORBA or WS-*, whether it's "better" in a global sense or in some application-limited sense.
Are PUT and DELETE Essential? The universe will not end in an ontological segfault etc. Also, you won't even stop being RESTful, assuming you have proper resource design, as per my first entry in this series. What you'll give up is the ability to make various reliability guarantees. I was going to say you also give up the ability to avoid the lost-update problem, but I guess you could do that with POST, so long as (yes) you were POSTing to the same URI you sent GET to earlier.
I don't know how good an argument this is anymore, but: designing with PUT and DELETE forces you to think in terms of resources. It's a form of discipline, like eschewing cookies. When you've got "read data" and "whatever!" it's very easy to think in terms of operations, flex your ten-year-old web application muscles, and end up with a mess like the Flickr web service. The vocabulary is negotiable. The underlying idea, (that a URI designates an object which responds to a standard vocabulary) is essential. That's the Architecture of the World Wide Web.
Is "Do Like the Web" a Good Argument? Not in and of itself, because parts of the Web are lousy. You need a tool to separate the good from the bad. I follow the admonition of Paul: "Prove all things; hold fast that which is good." Look at what people love about the Web and see if you can bring that same joy to distributed programming. Look at what people complain about and try to eliminate those things, whether you're building web applications or web services. When you find something that improves the distributed programming side of things, bring that knowledge back into the field of web application design.
Where Are The Tools? Traditionally this question has been answered by assertions that the (HTTP-level) tools already exist. As annoying as this answer is, it's technically correct. Without additional abstractions on top of HTTP/URI/*ML, there's nothing to write tools about. As we invent those abstractions (AtomPub, ROA, the ActiveResource control flow, OAuth, WADL, etc.) we write more tools. I'm writing tools now. As we get more practice the higher-level tools will get better, and as they get better they'll consolidate (as will the abstractions beneath them) and there will be fewer.
One thing I'd like to add is that it would be cool to see the existing frameworks for web applications apply some of the principles people have come up with while using the Web as a distributed programming environment. Make it easy to publish resources rather than operations, easy to support conditional GET, easy to write client interactions that respect statelessness. Rails has the right idea here.
Tue Aug 19 2008 15:28:
That one deserved its own entry. Onwards! (Again, here's the document I'm responding to.)
under a Creative Commons License.