I’ve not used it myself, but conceptually I’ve always been very interested in WSGI (the Python Web Server Gateway Interface). WSGI defines a standard interface between web servers and frameworks, giving python web applications the same portability that Java servlets enjoy, and also makes it much easier to layer code—with a standardised interface you can easily add in extra components to process your input and output before or after your main framework has handled it.
So say you had an application with a great web interface but no API to handle the input format of your choice. With WSGI you could intercept the API input and convert it before it ever hits the main application, making the whole process transparent to client and application. These two articles at xml.com are a good overview.
Ruby doesn’t have the same profusion of frameworks of python or java, but that transparent layering is still attractive, and a standardised interface makes it much easier for developers to put together experimental new frameworks without waiting for mongrel or another server to support them, or to build pluggable middleware. And that’s where Rack comes in.
According to Christian Neukirchen in an introductory blog post “dealing with HTTP is rather easy” and the core API of Rack is simply a method call that returns a hash of response code, response headers and response body. From that same blog entry:
class HelloWorld
def call(env)
[200, {"Content-Type" => "text/plain"}, ["Hello world!"]]
end
end
There aren’t many examples out there yet, but Johan Sørensen has a very simple example framework and a bit more discussion on his blog. There are also several sample adapters for existing frameworks available. What would be really nice to see next is an implementation of the atom publishing protocol using Rack, along the lines of this WSGI implementation. This could well be a project to watch.
Tags: frameworks, http, middleware, Python, Rack, ruby, wsgi