As I mentioned in a previous post, I was a bit busy this weekend while being sick on the couch. In this post, I'll ramble a bit about my server-side dabbling. Cutting to the chase, here's an XSLT filter implemented as WSGI middleware:

• http://www.decafbad.com/2005/07/xmlwiki/lib/xmlwiki/xslfilter.py

Now you can apply XSLT magic to your REST APIs, like Amazon does with theirs.

Update: Oh yeah and apropos this righteous rant against frameworks, I think one of the reasons I've been so taken with WSGI is that it's not another damn framework.

Discovering WSGI

First off, have you heard of this WSGI thing for web apps written in Python? I had seen some burblings about it some time ago, and got the impression that it was fairly shiny, but I hadn't really bothered wrapping my head around it. Now that I have gotten it lodged somewhat into my cranium, I wish I'd bought into it years ago.

I've been trying to reinvent a decent abstraction for web apps that can run as both CGIs and web-server-resident modules (whether in Apache, SimpleHTTPServer, or who-knows-what) in Python for ages. I'd found a few different ways to do it, but none as agnostic or no-nonsense as WSGI. And, not only did I find WSGI to be clean & simple--I realized that it also makes web apps composable.

So, like, if you have a web app that follows the WSGI spec, it can be swallowed up by filtering apps. The filtered apps can have any number of mammoth Python web frameworks powering them, and the filters can be as complex or simple as you want. Hell, build a web framework entirely out of composed filters!

I haven't quite wrapped my head around it yet, but I gather that this is part of the purpose of Python Paste--although I could be wrong.

An XSLT filter as WSGI middleware

Anyway, one of the main reasons this composability feature of WSGI has me in such an excited state harkens back to two posts I made on next generation web apps and a semi-aborted attempt at a demonstration of such an app. See, one of the components I've considered to be key to my tinkering with HTTP-and-XML web apps--more specifically, apps centered around REST APIs--is an XSL filter somewhere in the chain.

The first place I saw this technique used was with Amazon's Web Services and their REST API which accepts the URL of an XSL stylesheet to be applied as a filter to the XML resulting from a query. So, you can prepare some XSL of your own and fire off a request to Amazon as a specially-constructed URL--in return, you can magically receive a product search in HTML or even RSS/Atom directly.

Now, imagine more than that: Include XSL filtering in a REST API. Transform the plain old XML results of a GET request into a full-on XHTML/CSS/JavaScript browser-based application primed with that data. Include the interactive UI for further drill down queries, as well as forms for submitting edits of the data back to the server via POST/PUT/DELETE using XmlHTTPRequest.

That's where I'm headed with my experiments, whether I actually get there or not. In the meantime, I hope the XSLT filter as WSGI middleware is useful to someone.