James Tauber

journeyman of some

blog > 2006 > 01 > 25 >

Python Web Frameworks and REST

When I've looked at Web frameworks in the past (not just in Python) I've been disappointed by their lack of a resource-oriented focus.

RESTafarians like myself typically want URIs to map to objects that then simply implement HTTP methods (assuming HTTP is what's being used—REST isn't limited to HTTP).

I was aware of mnot's Tarawa experiment but hadn't seen that sort of approach adopted in any other projects.

In Leonardo, I started down the path of being resource-oriented but it is still somewhat half-assed.

In Demokritos, I wanted it to be a focus from the start. This makes a lot of sense with the Atom Publishing Protocol because APP is really just a subset of HTTP. You have to be able to handle PUT and DELETE verbs, support reading and writing of HTTP headers and be able to return proper HTTP response codes.

(Incidently, my understanding is that something like Ruby on Rails is a bit of disaster in this area.)

Although I haven't released a version with this yet, I've refactored out the general resource-oriented HTTP parts of my Demokritos code. You can take a look in the svn repository at webbase.py for the module and server.py for a specific example of it in use for the Atom Publishing Protocol.

Since I started on Demokritos, web.py has come out. It takes a similar approach, does a bit more (especially in dispatching - where webbase.py currently lacks), but I think I still like webbase.py more.

Very recently, I've started talking to Sylvain Hellegouarch and it sounds like CherryPy might increasingly enable a RESTful approach so there's a possibility at some point that Demokritos could move over to CherryPy (which would probably mean Leonardo would too if Leonardo becomes a layer on top of Demokritos).

In the meantime, check out webbase.py. I welcome feedback on it—especially from other RESTafarian Pythonistas.

UPDATE (2006-02-10): The link to webbase.py above is now incorrect. See pyworks.web.

Categories:
prev « python » next
prev « atompub » next
prev « leonardo » next
prev « demokritos » next
rest » next

Comments (12)

anders pearson on Jan. 25, 2006:

i've been playing a lot with writing little REST applications on top of cherrypy lately.

what i'm using at the moment is my RESTResource mixin, which you can grab out of Tasty's svn (i haven't packaged it up seperately yet, but i plan to): http://tasty.python-hosting.com/file/trunk/tasty/rest_resource.py

it's not perfect but it at least makes it pretty easy to map verbs to methods on resources. i'm not real happy with the API, but i haven't really seen anything else before to compare it with. i plan to take a close look at webbase.py though.

Sylvain Hellegouarch on Jan. 26, 2006:

Hey there,

CherryPy 3 is currently under brainstorming before being first draft. There some feature we do want such as the ability to change the URL dispatching at will depending on what is required for a given application.

One dispatching rule I do want is the one based on HTTP verbs. So it might take a few months to get there but eventually it will be a built-in :)

- Sylvain

Roman on Jan. 29, 2006:


From my perspective it would be great to have a unified approach to cope with query or filter requests in RESTful Python applications.

Examples:
GET all users that are member of group 'admin' and that have been created before 10/10/2003.

GET all blog entries that match a given fulltext query.

Don't the HTTP verbs lack a verb for search/query/filter?

Doug Winter on Jan. 30, 2006:

Using some of the ideas from RESTResource, I've been building a TurboGears app using RESTful URLs. No problems so far - it works very nicely.

Only Zope of the current crop of python app servers would have trouble with RESTful URLs, that I can think - the rest (ha ha) ought to be able to handle them fine?

ToddG on Jan. 30, 2006:

I'm not very clueful in the REST world, but if you need lots of control over URI mapping to function/method calls it would seem you'd be able to do more or less anything you need using something like Myghty's resolver (http://www.myghty.org/docs/resolver.myt). Or maybe the Routes library from groovie.org ? Sounds like this is somewhat like what is planned for Cherry?

dbt on Jan. 30, 2006:

ToddG, the two essential things you're looking for in a RESTful framework are logical URL mapping showing separation of concerns, and no confusion between GET and POST.

James Tauber on Jan. 30, 2006:

dbt, I would add that URIs should identify objects, not actions.

So instead of /listUsers, /addUser, /deleteUser, /updateUser you have GET /users, POST /users, DELETE /users/[user_id], PUT /users/[user_id]

Andre on Jan. 31, 2006:

Not to be a troll or anything, but why is using REST so terrific, and why is something like Rails' routing scheme so bad? Am I correct that the point is for a url to be aligned with the resource that produces it? I think I'm missing something here, because in my experience, that's a perfectly awful situation.

James Tauber on Jan. 31, 2006:

Developing services on the Web in a RESTful manner is the best way to ensure they'll play nicely with the rest of the Web. In short, a RESTful use of HTTP means using HTTP the way it was designed.

Sometimes that can be as simple as understanding the difference between GET and POST. Remember when Google's Web Accelerator came out and broke a bunch of Rails applications?

REST means giving your objects URIs and a uniform interface (such as the one HTTP provides). With a RESTful service built on HTTP, for example, if I know an object's URI, I know how to retrieve the object, I know how to delete it or how to replace it. I can cache it, go through proxies or potentially ask for it in different formats. When things go wrong I get standard error codes. And all of this is without having to know anything specific about the service.

The Atom Publishing Protocol has adopted a RESTful approach. This basically means it only has to do 10% of the work because the other 90% is provided by generic HTTP and the Atom Syndication Format. This also means it's very easy to implement the protocol if you have a good RESTful framework. You'd have to jump through a lot more hoops to implement APP if you're sitting on a framework that doesn't support the RESTful nature inherent in HTTP.

At the very least, implementing something like APP requires a framework that supports PUT and DELETE just as much as GET and POST and a framework that makes returning a 204 or a 201 or a 415 response just as easy as a 200.

Julian Krause on Feb. 13, 2006:

Hello, I am the lead developer on RhubarbTart. I was lead here by an article by Dave Warnock http://42.blogs.warnock.me.uk/2006/02/james_tauber_py.html

I am currently working on designing a new controller for RhubarbTart that would make creating RESTful resources easier in Python. You would be able to use an object mapping like what CherryPy already does but also put GET, POST, PUT, DELETE, and other methods into the class or attach them onto function names in order to call those functions upon that method being called. I hope you will take a look at it as soon as it is released

James Tauber on Feb. 13, 2006:

Definitely, Julian.

c on Aug. 13, 2006:


I was searching for a similar REST + python setup recently. This looks interesting:

http://lukearno.com/projects/selector/
Created: Jan. 25, 2006
Last Modified: Feb. 9, 2006
Author: jtauber