I was looking this unassuming post from a while back, and thinking about callbacks from this comment, and I started getting that annoyed feeling about REST and HTTP verbs, but I wasn't sure why. Now I think I know why: the way HTTP verbs are being suggested they are a poor substitute for callbacks, and callbacks are easily attainable right now if we just pay attention to them.

To summarize the verb argument (as I understand it): using different verbs on the same resource allows you to make a cohesive set of actions that work on a well-defined entity, and the entity is represented by the resource URL. Because the HTTP verb is orthogonal to the resource URL, you keep object and verb very separate.

What do the verbs mean? This is communicated via some other channel, probably documentation. It is not always self-evident. DELETE means delete? Only if you have a dumb container. If you don't have a dumb container, DELETE probably means more than just delete -- it has side effects outside of the resource in isolation.

I was reminded of this again with Mark Nottingham's post about links, which is this idea of callbacks again, about defining explicit relationships instead of implying. He extends it with link templates, like http://www.example.com/home/{userid}, which can represent some more complex relationships. One of the nice parts about something like this is that http://www.example.com/userhome.php?userid={userid} works just as well in this scheme. That is, it works for the systems we have now, not just the systems we want to create in the future.

The problem with depending on "RESTful" URLs, verbs, and other contracts is that it isn't the web we have now. And it's definitely not a simpler web, because the web we have now isn't going away. There are complaints such that userhome.php?userid={userid} isn't likely to be a stable URL. Well, creating a new URL scheme for the site certainly isn't the way to solve that!

Good designs have to deal with what we have, not just with what we wish we had. You have to embrace the problems, recognizing them as part of the success. The W3C's pursuit of XHTML over enhancing HTML is one such example, and we've all spent a whole lot of time accomplishing nothing as a result. Much of REST is great because it embraces what we already have, because it describes the systems that already work well. But some of what goes under the REST flag does not fit this. The systems we have now do GET and POST really well; everything else is spotty. If we need more than GET and POST, then that has to be resolved. But I don't see why we would need more; those two verbs describe just about everything we need, and they do it with a proper amount of vagueness, not describing much more than what they can deliver.

Something like Link Template headers (or even more conservatively <link>) provide a much greater vocabulary, and they are so wonderfully composeable compared to HTTP verbs. I think that's a much more interesting direction.