Microsoft coding guru Tim Ewald got a lot of people talking when he announced I finally get REST. Wow. and followed up with Three reasons that REST is not RPC. It’s nice that the word is spreading, but many REST converts see complicated magic where I see a few simple easy-to-understand virtues.
Naming Things · People don’t recognize how important URIs are. The notion that you have a huge, world-scale, information space, and that everything in it has an name and they’re all just short strings that you can paint on the side of a bus; that’s a new thing and a good thing.
REST theoreticians make extravagant claims about hypermedia, but it seems to me that computer programs have always needed to refer to things, and computer programs that send messages have always needed to put those references in the messages. URIs just provided a uniform way to do this, and it was easier and less complicated and shared across all applications that wanted to play in Web-space.
Messages All The Way Down · HTTP is a decent and under-appreciated protocol, but in the end maybe the most important thing is that it forces you to think about the messages and how you exchange them. There’s no pretense that Remote Procedures are being called, or Object Models are being shared; I send you some bits and some metadata about them, and you respond with the same. It turns out that in the HTTP universe, at that point our conversation is over, and that turns out to be a good basis for building applications, but the key thing is putting the messages, rather than what they allegedly stand for, at the center.
Yummy Protocol Goodness · I don’t know if there were any other explicitly message-centric protocols in play when HTTP came along; if not, we’re lucky that it hit so many sweet spots.
For example, it turns out that HTTP being one-request-one-response forces you to think explicitly about state and where it should live; there’s no one correct answer to that question (yes, cookies are OK sometimes), but applications where the designers had to think about it are generally better than the other kind
Another sweet spot is the absence of URI metadata and the closely-coupled “404 Not Found”. The only way to find out what a URI identifies is to try to retrieve it, and it’s perfectly OK if the network says “I dunno”. Because that’s how the world is, and protocols that map the world accurately are generally better than those that don’t.
Then there’s the notion of dividing all the transactions into three buckets: commitment-free (GET), idempotent-update (PUT/DELETE), and Other (POST). Hard to argue with and theory, and the GET and POST parts are well-proved in practice.
Theory is OK · I think Roy’s thesis is an outstanding piece of work, but it’s important to remember that he worked on the software first, for years, and at some level REST is a an attempt to retroactively paste a layer of respectable theory over some stuff that happened to work. For my money, that’s the best kind of theory; but the real truth is in the software, which works really well.
So if Tim Ewald wants to think about his apps as State Machines, and if someone else wants to think of them as Hypermedia Platforms, and someone else as a Contribution Commons, that’s well and good. But at the end of the day it’s about having good ways to name things and a clean simple message-centric protocol that’s not trying to pretend to be something else.