Jan 16 2007
REST is Functional
Something that hadn’t occurred to me, but in retrospect seems obvious now:
It’s interesting to note here the connection between REST and functional programming and the meaning of the word ‘function’. For most developers a function is a sequence of statements that do some ‘work.’ But for the few developers using a functional programming language a function is a well defined relationship between an input and output state. RESTful systems manifest the latter, ‘functional’ meaning of the word ‘function’. You might describe such a system as ‘B:HTTP(A)’ where a given HTTP request acts as a function and is applied to system state A. The application of this function in turn generates a new system state, B. In the end, as Duncan points out, many of benefits that RESTful systems have over SOAP are analagous to the advantages that functional languages have over procedural languages.
This is from a blog called discipline and punish which I’ve not come across before. Lots of interesting stuff there on OpenID, and a rant on syntax obsession that fits well with a current Talisian discussion.
2 Responses to “REST is Functional”
My original point, which has been excellently picked up on and explored in that blog you linked to, was that REST is /Declarative/.
There has been a discussion recently on rest-discuss (Yahoo groups), where Benjamin Carlyle characterised a REST interaction pattern by the concept ‘make it so’ (Declarative) – rather than ‘do this now’ (Imperative):
> .. REST replaces the doSomething concept with a “make something so”
> concept. If you think about it, all doSomething can be modelled
> this way. .. “make your state this”.
I take this further – into a general Declarative REST programming model – by allowing resources to ‘make their state so’ /all by themselves/, according to rules or constraints and according to surrounding peer resources.
I eventually wrap up all the loose ends by making the /user/ such a resource, and able to interact with and like other active resources – they declare an intent to ‘make this so’ in a GETable – or at least POSTable – way, in the body/content type, not the headers (i.e., without PUT or DELETE).
But I ramble on. Only because this is all in my head right now and your blog hit my Google Alert just a minute ago!! =0)
Cheers!
Duncan
I think Web applpications in general (perhaps bounds blur with AJAX) are essentially functional.
In a Web application framework I’ve recently built I find myself looking at a bunch of stateless, static handlers (they’re not actually static by virtue of the fact we’re using Spring and the contraints of the lightweight container).
My point is, I don’t think this is necessarily a REST issue. For a wide scope of Web applications the URL is the primary call interface, and state is often (at least in part) carried or at least cued from the URL. *shrug* It simply is a pretty functional set-up…. actually I think the issue as to whether it’s functional or not is down to whether or not you’re communicating state across the URL.
I confess a bias of disinterest in REST however. I’ve always felt it a distracting sideshow that has in the past left me thinking “so what?”
I find Duncan’s slant on declarative and imperative interesting… I’ll have to think on that more.