After a fairly reasonable flight from London (I can't believe that I can find 23 hour flights reasonable nowadays) I arrived in Sydney to attend and present at the Australian Architecture Forum. The theme of the conference this year was exclusively SOA (to the detriment of other interesting architecture themes) and a great number of the presentations that I attended were on REST or some variant of the old REST versus SOAP debate.
Still it's pleasing that enterprise architecture folks are talking about Web architecture at last, but I was a little dismayed at some of the understanding around the topic. I'd make Leonard and Sam's book compulsory for any speaker. As a side note I'd ask any REST proponent what HTTP 409 is just to check whether they grok it, rather than using the Web as a crummy 200/404 XML-RPC mechanism.
Anyhow, here are my distilled notes and corrections mostly for my own convenience because I seem to answer these questions a lot day to day. Maybe they'll be useful for you, maybe not. The names have been changed to protect the innocent and ignorant.
REST is simple.
I've heard this quite a lot today and I have a feeling it is true if and only if:
1. You are a genius of the level of Fielding,or the other inhabitants of REST-Discuss; or,
2. You don't get it.
That is to say for most of us practitioners, REST isn't simple. It is well understood but it is not a panacea the way it has been presented here today.
(Popping the 409 question indicated, informally, that (2) above was the majority case)
REST won't work in my situation.
Yes, you're right. Absolutely. Your situation is unique and you are special.
But if you could change your situation REST quite possibly could work. After all it works for all those gazillions of people and programs on the big Web. Perhaps if your enterprise architecture was more aligned with the Web, rather than a special-case enterprise fantasy architecture, you'd have a fighting chance.
REST is all about CRUD.
No, it's not. It's about following links and asking for metadata to help you process the resources those links identify. If you treat the Web as a CRUD platform, you're missing out on the good stuff.
You can't do pub/sub with REST.
Not true.
Atom feeds with reverse proxies (for scalability) are a great publication scheme. Anyone who's authorised can subscribe to those feeds (and even with AtomPub have a way of updating them). The challenge is to figure out the optimal size for a feed and to figure out a sensible way of maintaining information once it drops off the head (identified by a canonical URI) of a feed (like using link="previous" or similar).
Serendipitously, this model helps with the notion that a newly switched-on system is the same as a system implementing crash recovery - the data needed to start or recover is in the cloud, which is nice.
Apart from UDDI, all the WS-* specs are new solutions to real problems.
See WS-Transfer and friends for counter examples. (Coincidentally I think those dark days were the beginning of the end of the WS-* affair for me).
REST has reach.
Oh yes it does. Or at least the Web has reach. Everything knows about the Web. Scratch one up for the good guys (and Stefan Tilkov who informs them, and Steve Loughran for joining the dots for me!).
HTTP just maps to a database.
Yes it can, but isn't that the most trivial thing you can do? Treating the Web as a CRUD framework is like using a thoroughbred race horse to pull a cart.
The RESTful support in WCF is limited to (cacheable) CRUD and you define which verbs apply to which URI templates at compile time.
Oh dear. Resources tend to change which verbs they respond to over a lifecycle which isn't limited by compile-time choices. Yes OPTIONS is hard, but why ignore it when you are building frameworks so that we Morts can do REST? Because you're wedded to static contracts, that's why. Welcome to the IDL-isation of REST.
If-Modified-Since is less accurate than and ETag and If-None-Matches.
Yup, true. Timestamps are also cheaper than hashing internal data structures or managing UUIDs so think carefully about sub-second changes and decide if they're important to you or not.
You only need to know 5 HTTP response codes: 200 304, 400, 404, and 500.
Nonsense. 201 and 401 are pretty common, and 100, 409 and 412 are essential for anything but CRUD demoware.
Update: 201 gets a mention a few slides later on, as does 409. Yay!