Folks can get a wee bit post-modernist sometimes in intellectualizing REST. I am guilty of doing a bit of that because it hits on some many of my hobby horses: the relationship between proper nouns and query expressions, the relationship between regular and irregular verbs and why human language has both, the relationship between what is known as "information integration" and what is known as "process integration" and how mashups really crystallize the issues surrounding pull- and push-centric design.
If I had to pick one para that, for me, gets to the heart of REST, to add to Tim's list it would be this:
A lot of EAI which, on the face of it, appears to call for full-on, push-centric, reliable coupling of systems, can be recast in much, much simpler pull-centric form that requires nothing more than
- A well designed information space mapped directly into de-referencable URIs
- Proven, off-the-shelf HTTP tools and data formats
- A simple, pull-centric, cache-friendly way of telling when something interesting has happened in the information space
Anybody who things Mashups is just Google maps has missed the real point. This is understandable given the explanatory power of visualisations but the mashup phenonemon is about much, much more than just slapping data on a cool map. It represents nothing less, in my opinion, than a re-casting of the question "how to we integrate the business process in application X with the business process in application Y? Is there a dramatically simpler solution to the push-centric, trasactional, reliable once-and-only-once one that human language has a way of veering us towards?
Most of the time, yes, there is. Start with REST and ask yourself this question: "if applications A and B both push out the information that needs to be integrated into HTTP space, can I integrate A and B just using, say HTTP GET and maybe some RSS/Atom eventing?". I predict you will be surprised at just how far that can take you. (Critical hint: Remember GETs are read only. If your business analysis tells you that A sends X to B. Recast that as A publishes X into URI space. B GETs X from its URI. If B cannot GET it for whatever reason, it just GETs it again.