Django and Web Services, part 2

Back in August 2009, I promised to tell you more about my experience using Django for a web application in front of a web services interface to the backend data store.  Now that the code for the Trident Project has been released, I can be more specific and point you to the code if you’d like to explore it further (yes, yes, I’m behind on documentation).

Initially I tried to use Django models and managers because I think the APIs are elegant, and of course there’s the DRY principle.  I knew I wanted an object API — no way was the web app going to deal with raw XML.  Django 1.1’s “unmanaged models” opened the door, but the deeper I went down the rabbit hole, the more I came to feel that I would have to bend the API way out of shape, if it was even possible.  Ultimately, Django’s API is too tightly coupled to SQL backends  (I’m not up on Google AppEngine and django-nonrel).

So, ultimately I broke it down this way.  There are three layers in the client code:

  1. A “middleware” layer that handles the basic HTTP request/response cycle with the RESTful web services.  At this layer I have used httplib and pycurl.
  2. An object layer (which I call “entities” because they model the backend objects, which are referred to as entities).  This layer handles calls to the middleware and marshalling the response data, and applying some lazy techniques.  This layer is not coupled with Django and can be used on its own — very conveniently, for example from the Python interactive interpreter — or underneath another web framework.
  3. The Django web application layer which deals with the backend system exclusively through the object layer.

This is a work in progress, and needs a lot of refinement, but I’m pretty happy with how it functions by keeping the those three distinct concerns cleanly separated.

I’d love to hear how others may be using Django in similar ways.


, , ,