Duncan Cragg's Business Functions | The REST Dialogues just blew my mind.
Here I was, all this time, thinking myself a RESTafarian. I had however, always believed there was a place for RPC-styled invocations. This is largely, no doubt, from the work I did on my previous project, Jazz, where we started with RPC-styled web services, and then added some REST ones. In my mind, I've been thinking all along that REST and RPC-styled services, together, are what it takes to feasibly build a complex web services based system.
But something about Duncan's arguments rings true with me.
One thing does cause me concern though. And that is dealing with concurrency of 'objects' on the server. Once your individual POST requests end up having to hit multiple objects, locking them, you need to start to be concerned about deadlocking. Not that this wasn't a concern before, but it's still a concern here, though Duncan seems to brush it aside too casually.
I'm not sure I believe everything can be boiled down to state-transition tables, but certainly it would be nice if they could. Makes me wonder if things like BPEL (well, a non-XML version thereof :-) make more sense than they otherwise seem to, to me, today.
My most interesting thought though, was what this means to programmers, in terms of the APIs they use to invoke these services and get the results back. RPC maps wonderfully to function/method call patterns. Do we really end up living in a world where every web service has the same set of method names available (but different typing for POST parameters, and POST and GET results)? hmmm. How else might we able to make the protocol interaction more palatable to ordinary programmers used to defining, implementing, and calling methods and functions that are more RPC-ish? Or is a functional programming style, that this interaction pattern seems best suited for, just the obvious way to do it?
Anyhoo, got some back-reading to do this week ...
As an aside, I also love the dialog style of argument that Duncan used. Not sure why, maybe it's easier to read than straight through narrative. Steve O'Grady also often does this, and I've tried my hand at it as well.