Peer Pressure

Stuff to look at about looking at stuff. From Chris Dent. What?



REST, I just want it

Yesterday I was in London for an Osmosoft TiddlyWiki hackathon. I didn’t get much hacking done but had several very valuable conversations and met some good folk. Running throughout these conversations were threads of REST, HTTP, web and software architecture. Common to these threads was a lack of consensus about what counts as “good” in any of those contexts and what concepts shared in those contexts could be be considered good in a more universal sense.

So it was with some pleasure that I woke up this morning to see that Simon Willison had linked to Damien Katz (of CouchDB fame) saying REST, I just don’t get it. The comments are instructive in two ways:

  • They provide a lot of good and varied input on why thinking about software systems in a REST kind of way is useful.
  • They show that the rest of the world, not just some guys at a TiddlyWiki hackathon, are also lacking in consensus and shared understanding when it comes to web architecture.

In the end it is all really quite a subjective matter of opinion and in such cases, a diversity of opinion is a great way to learn, explore, find the edge cases; to gain new perspectives. So with opinion being the operative word, here’s where I think recent commentary gets it right and wrong.

While talking with Martin and Fred yesterday about the TiddlyWeb API Martin made the statement that it is generally accepted wisdom that minimizing the surface area of an API is good practice because it allows the most stability at the surface while allowing internal change. I agree with this.

chu’s comment:

I think only allowing up to 4 methods is a key benefit. Having to express an app through nouns rather than verbs leads to a much cleaner, more robust and encapsulated design.

says sort of the same thing, from a different angle. It also introduces my favorite bit about systems that try to have a REST style: nouns; the parts of the system as resources on which there are a very small number of operations that can be performed. Building blocks, lego, in a system with a simple grammar but complex expressivity.

Damien says:

I guess what I mean to say is just because SOAP is a disaster, doesn’t somehow make REST the answer. Simpler is better, and REST is generally simpler than SOAP. But there is nothing wrong with a plain old POST as an RPC call. If its easy to make all your calls conform to the RESTful verb architecture, then that’s good, I guess. But if not, then just use a POST as an RPC call, keep it as simple as possible and be done with it. And don’t spend another minute worrying about being RESTful or not.

I think there’s right and wrong in here and one of the comments nails the problem. Avdi says (my emphasis):

One of the big (but non-immediate) wins is explorability. If you don’t care about emergent properties, if you don’t care about what other people might build on it, then sure, use nothing but POST; use SOAP; use CORBA, for that matter. The magic of REST is that no WSDL or IDL can replicate the experience of someone clicking around a RESTful API in their browser like a kid opening up a box of Tinker Toys and saying “yeah, I get how this fits together! I could build on this!”.

RESTful services are easier to build on, especially when the things being built are things the providers of the service couldn’t or didn’t predict. I use the term service intentionally. If you’ve got yourself an application, where you want to control the user experience, then whether you use a REST style of architecture or an “RPC call” might not matter.

Unless, that is, you are concerned about scalability and availing yourself of the caching capabilities of the web. The comment from Colin Percival hits the REST association with caches.

Not mentioned in Damien’s discussion, but present, at least tangentially in yesterday’s hackathon is what I think is perhaps the most interesting part of having a web oriented frame of mind when thinking about software system design: pipelines, chainability, stackableness, composability. The Lego Factor. For people who grew up on a unix-like command line this is the feature that separates the good from the bad.

A web service that is built upon RESTful principles is easy to pipeline because it has a small and well known API (some or all of GET, PUT, POST, DELETE) that makes it possible to GET a representation from one service, transform it in some fashion and send it on to another service.

The WSGI specification for Python helps extend this model down into code with simple middleware that transforms either the web request or response. This is awesome because it helps encourage code modules which are encapsulted and decoupled while not requiring a adherence to a bunch of framework. These modules are just like web services but running in the same process space.

I could go on endlessly here. To sum: RESTful principles are for the most part an expression, in a distributed space, of a lot of time worn wisdom about how to make good software systems that are reusable:

  • minimize complexity
  • maximize discoverability
  • minimize exposure of special knowledge and methods
  • maximize opportunities for reuse and chaining

Damien’s right that some of the time the principles aren’t going to be right for a particular use, and there’s no point getting in a twist about them. But it is obviously true, that on the web, designing and building with respect to what works on the web is good. Tim Bray gets the nod for that. His comment is a good ending:

Well, a REST architecture serves as the basis for the most biggest and most successful information system the world has ever seen, that effortlessly deals with heterogeneous hardware and software, and provides a high-quality user experience while scaling towards a billion users. So think of it, as nothing else, as a good benchmark that you have to be better than.

What about REST makes you want it?

Comments (View)
blog comments powered by Disqus