Clearest Explanation of REST Yet
REST is refutation of Web Services (WS-*)
Sometimes a concept is so vague that you spend years trying to understand it. And one day, you get it.
Here's one example of me getting OLE way back when.
REST has been something that I've heard a lot in the past couple of years. I've been to numerous internal as well as local user group talks on the subject. I read articles in online magazines. I've heard testimonies on how a little bit of rest did wonders in decoupling an otherwise tangled mess.
However in the back of my mind there is a nagging feeling that I have not understood the concept completely. It didn't help that the explainers invariably resort to "it's an architecture style," or "when I GET the URL http://host/car, I'm getting a representation of a car, which is a resource, and my state is transferred," followed immediately by an apology, "I know. I know. It's not the best of explanations on earth."
Then I read this tutorial on REST Web Services, referenced in John Cowan's weblog. And it all clicked for me.
I'll let you read the tutorial yourself since it's a rather long one (148 slides.) Here are two slides that resonated with me the most:
The Unix Way
- Files have a generic interface
- All resources in the system could be accessed through these narrow interfaces
- Some things were always exceptions
- Unix networking broker this philosophy
- The Plan 9 research OS restored it, doubled and in spades
REST from a Unix viewpoint
- Resource rather than files
- URI space instead of the filesystem
- A slightly different (even narrower) generic interface
- But the focus is the same: a generic shared abstraction, not point-to-point interface coordination.