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.
Contributions
Comment feed for ongoing:
From: Steve Loughran (May 02 2007, at 00:56)
I know Tim was at MS (he did a lot of the MSDN site architecture), I don't think he's been there for a few years. Best to check with him.
-steve
[link]
From: Tim (May 02 2007, at 02:23)
No, Tim isn't at Microsoft any more, but he's still a Microsoft Coding Guru, as in authoritative about all manner of development issues for the Microsoft platform.
[link]
From: John Cowan (May 02 2007, at 07:02)
Metacomment: calling yourself "Tim" and talking about "Tim" in the same breath is very confusing. Only mousing over the link revealed that you weren't Tim Ewald talking about himself in the third person, which is what I first assumed.
[link]
From: James (May 02 2007, at 11:01)
I work for the student computer labs at a public university. I have to keep straight:
Mike the hardware guy
Mike the software guy
Mike the tech guy for the department my lab's in
Mike a student employee in my lab
Mike another student employee in my lab
Only two Tims? I laugh.
[link]
From: Drew (May 02 2007, at 13:50)
"George likes spicy chicken!"
Sorry I couldn't resist.
One thing about REST that's nice is you can test with a browser. One thing about REST that's a bummer is you have a very hard time googling things like "Applescript and REST"...
[link]
From: Andrew Wahbe (May 03 2007, at 08:47)
I think Tim Ewald is saying something new -- or at least stressing an aspect of REST that's usually ignored. I don't think you can dismiss it as "just saying the same thing but in terms of state machines". The "hypermedia as engine of application state" aspect of REST is really important IMO but rarely mentioned. Most people focus on uniform methods (and go on and on about whether they map to CRUD or not), naming everything with URIs and standard data formats. We need that transfered data to constrain the set of possible next states in the application. Links in the data is a start, but we need to think about more powerful ways of encoding the possible next steps. We need to be able to dynamically construct a URI or the POST content as we can with forms. We need to be able to express complex, multi-step interactions such as using if-match for unreserved checkout. We can do this with HTML today but there's no general, standard mechanism for this in machine-machine hypermedia. I wish the community was focusing on these issues rather than things like WADL -- which is just a header file in the end.
[link]