Are RESTful Web Services Like Functional Programming?

This comment by bew caught my attention on a recent post of mine.

It’s a bit funny that someone interested in Haskell is that negative about REST. With REST, GET and PUT are like pure functions. You will always get the same result, irrespective of how often you call them with the same parameters.

It’s interesting to me, not so much as a statement about REST, but as a statement about ways of understanding functional programming. Ultimately, it boils down to why functional programming languages are a good idea in the first place. So here’s a quiz.

Question: Why are functional programming languages a good idea? (Select all that apply.)

Because one can safely do the same thing over and over again.

Mutation belongs in comic books, and has no place in programming.

They provide powerful tools for building abstractions.

They provide powerful tools for analysis of programs.

My answers: 3 and 4 only. I really don’t fundamentally care about answers 1 and 2. The definition of referential transparency and the lack of mutation are by all means obvious and visible aspects of functional programming, but the importance of functional programming is not tied to any desirability, in and of itself, of idempotence or lack of mutation. Functional programming is worth anyone’s attention only because it occupies a nice space in which powerful abstraction and powerful analysis, two goals that are often in strong tension, are both near at hand at the same time. That, rather than anything else, is why they are important and successful.

As bew says, some REST methods are idempotent, and mutation is clearly marked. Unfortunately, the more interesting bits are missing. Indeed, there is active resistance in the “REST is cool” groups toward building any further abstractions at all on top of REST, and I see only limited support for an argument that transforming, manipulating, or analyzing REST services is particularly powerful either. REST isn’t alone in sharing some characteristics with functional languages (to the extent that it does, which is a stretch) but missing the benefit. It’s not even the best example. XSLT is way more purely functional in nature, and at least as fundamentally uninteresting to boot, as RESTful web services.

So my answer to the subject line: Are RESTful web services like functional programming? No, at least in any interesting way.

Does any of this mean I’m beelining toward SOAP? No; after all, no one could say with a straight face that SOAP provides powerful tools for abstraction or analysis either. RESTful web services may be a good idea for purely pragmatic reasons — poor quality of implementation of SOAP, ambiguous specifications, etc. That isn’t the popular claim though. The popular claim is that REST is some kind of ideal; a set of principles that should be applied to any communication delivered over HTTP. I still say hogwash.

6 Comments

Emulating purely functional style in languages that aren’t purely functional to the greatest degree that is reasonable and practical is helpful, like in OCaml or Scala, where mutability is allowed but is the exception rather than the default.

You miss the point of referential transparency. It’s not that you can safely do the same thing over and over again. It’s that parts of the code are separable. If you know what a pure function f() does, you don’t need to unit test f(x) for any x.

Paul, I came to mention Waterken, too. I’ve been following the development of the Waterken server for a few years now. I’ve found the concepts it espouses are really enlightening and novel. I’ve long held that MVC (Model-View-Controller) isn’t an appropriate methodology for web services; instead I think that a document-oriented paradigm is more suited.

Waterken takes this approach: objects are exposed to web clients by converting them to Hypertext documents, encoding their references to other objects as URIs. Every object in the system may have an addressable URI on which GET or POST methods can be invoked. Functions are treated as first-class, so they can get URIs, too. In this scheme, GET is equivalent to dereferencing, and POST is equivalent to a function call.