REST: Unix programming for the Web
Tags [ architecture, design philosophy, microservices, REST, REST programming, Unix, Web 2.0 ]
I’ve been giving some thought to REST-style architectures recently, and recently re-read some of The Art of Unix Programming by Eric S. Raymond. The author notes that some of the characteristics of Unix-style programming include:
- Do one thing, and do it well (attributed to Doug McIlroy)
- Everything is a file.
- Comprise complex systems by connecting smaller, simpler programs (e.g. Unix pipes).
Unix-style systems have had undeniable success and remarkable stickiness for a technology; I have an old copy of my father’s System V manual from when he worked at Bell Labs (yeah, they actually printed out the man pages and bound them!), and I pretty much recognize everything in there. Sure, there are many new commands available, new kernels, new distributions, etc., but they are all very recognizably Unixy.
I’ve been thinking about how this philosophy applies to the Web 2.0 world. I think this list turns into:
- Do one thing, and do it well.
- Everything is a RESTful service.
- Comprise complex systems by interconnecting smaller, simpler services.
For one thing, “do one thing, and do it well” isn’t limited to Unix, this is a key part of abstracting and decomposing a technical problem. But we see it everywhere: I read my mail on Gmail, keep my to-do lists on Remember the Milk, store photos on Flickr, keep my browser bookmarks on del.icio.us, etc. All these sites adhere to this principle.
But taking things down a layer, what does this mean to someone architecting or implementing a Web 2.0 service? For one thing, I think this means that it would make sense to break your overall service down into individual microservices that are individually maintained and deployed; i.e. break things down to the smallest level where they still make coherent sense.
As for “everything is a REST service”, the everything-is-a-file
abstraction worked for Unix because there was a small set of common
operations that applied to files (open, close,
dup, read, write). Sounds a lot like doing
REST over HTTP, with HEAD, GET, PUT, POST, DELETE.
Combining various small REST microservices into larger services is already being done (this is, after all, basically what iGoogle is) on a one-off basis. The main question is: what is the Web 2.0 equivalent of the pipe? Namely, is there an easily understood abstraction for composing webservices? Sounds like a topic that might be rife for some kind of logical calculus (like the relational calculus for databases or the pi-calculus for concurrent processes), e.g. the REST calculus. If there were a couple of easily understand and specifiable combinators, these could be pretty easily built into some language-specific libraries for use in quickly building some new macro-services.
I might try to interest some of my old colleagues from my programming language research days to see if they have anything to say about the matter….
Comments definitely welcome here. Is this a new idea? Are others espousing this? Is this even a good idea?