So what would a RESTish web framework look like? I don't see much point to focusing on PUT and DELETE or URI design, simply because it doesn't achieve anything new. That stuff can lead to non-browser architectures, which means that there will have to be an intermediary, and that intermediary will need a web framework, and the premise here is that we're thinking about web frameworks.

Maybe it's better to just think about the goals of REST... loosely coupled, less code, decentralized, scalable, maybe even vague ideas like democratic, hackable, avoiding consulting-ware, less code, etc. etc. Small pieces.

So... Anders Pearson posted about his RESTful stack, a concrete set of actual small pieces. It's not one beautiful diamond, but just stuff. Hopefully useful. The architecture is interesting when thinking about them working in concert, not reflecting on the beauty of any one piece. Many of the pieces are incredibly boring, in fact. Tagging, okay, but a RESTful hash table? (Well, he's not the only one doing that -- but clearly it takes a bit of imagination to see the potential; the queue stuff Amazon is doing is also pretty abstract.)

What's interesting -- and hard -- is doing something with this mix. How will we keep the architecture manageable?

The direction I've been focused on for a while now is how to use this style internally in an application. Because yes, you may want to move some RESTful piece of your app onto another server, onto another service, into another environment. But first you have to make something useful -- scaling tools is boring, and for most of us scalability isn't even the reason for REST. Only working web applications have to scale.

So how can you handle a simple application (like, say, a blog) built from a dozen RESTful components? Lots of mod_rewrite rules, several startup scripts, some XML configuration, a couple app servers... oh just shoot me now. Setting up systems gets geometrically more annoying and error-prone as you add the number of systems working in concert. Probably half of why people like the ASP model is just because installation is so damned hard. You could just use S3 from the beginning... but I find that a non-starter as well, when the distributed hash table is just one piece among many. And then if you think about automated testing... ASP-only just isn't an option.

But you can manage these pieces. That's what the small apps post was about. And that's what the architecture of Paste is about. I say the "architecture", because Paste includes several examples of the kind of small application/component that you would use in this situation. By sticking to WSGI -- kind of an HTTP-in-Python -- any piece can be fully a peer, and Paste itself doesn't have a privileged position. A larger system of these kinds of components is in the works, like Beaker for sessions and caching. For an example of how small an application might be, in Paste there's an application for sending a single file (paste.fileapp.FileApp), or an application for sending 404 messages (httpexceptions.HTTPNotFound.wsgi_application). It sounds tedious, but those applications are as simple to invoke as they are to describe (at least once you have the WSGI invocation part down).

In addition to these endpoints, there are lots of intermediaries that rely on the transparency of the request. These get called "middleware"... but ignore the terminology. An example is code that checks IP addresses against rules (paste.auth.grantip), or validates HTML (paste.debug.wdg_validate). Intermediaries and end-point applications are even fuzzy -- paste.auth.open_id does a little of both, annotating some requests and completely intercepting others (since Open ID logins span several requests). In the context of WSGI, authentication is solved. It goes in REMOTE_USER (recognizing the standards we already have, even if those standards are sometimes undervalued due to poor implementations in the past). How's REMOTE_USER get there? Out of scope! (Like REST, WSGI is as much about what it doesn't promise as what it does promise.)

Paste Deploy is then a way to bring these pieces together and configure them, since a website will be built from a bunch of pieces. The actual invocation looks rather primitive, but the important part is that configuration is another syntax for Python function calls. So when you build a cohesive application from these pieces you put them all in a single process, build them at fixed locations. You don't configure them independently, instead you provide a cohesive single view of configuration, and programmatically configure the sub-pieces.

Another issue with a highly granular REST stack is the HTTP overhead. This may be a case of premature optimization, but latency in particular is something that might bite you later. But because WSGI maps so closely to HTTP, you can make equivalent REST calls purely with WSGI and no network connection; this just turns into some function calls. Later on you can break it up, scale it out, configure pieces to be in different locations. If you need to... and you probably won't, and you may not know which pieces should be broken off to begin with.

Anyway, that's why I think WSGI and Paste have some potential to work well with REST; not because they respect some idea of the purity of HTTP, but because they facilitate realistic architectures that are highly decoupled with HTTP (or looks-like-HTTP WSGI call) bringing those pieces together