Comments on: Django Architecture Approaches

By: Adrian

Adrian — Fri, 11 Apr 2008 07:15:57 +0000

The description is basically a tree, with a first level of leaves with the resources (one entry per URL described in the urls.py file) and, for each resource, each exposed method (GET, POST, etc) with its documentation, parameters, etc. You can have this in any format (JSON, XML, YAML) depending on the “Accept:” header MIME type, or the “format” parameter either in the GET or POST collection.
I agree that it’d be great to make this project go forward! I think having a good REST interface in Django would make it useful for many new projects. Just a question, are you a committer of Django?
Cheers!

By: David, biologeek

David, biologeek — Thu, 10 Apr 2008 18:23:41 +0000

Looks great!

You Client additions reminds me a ticket where I’d already done that (partly): http://code.djangoproject.com/ticket/5682

What’s the format of the returned to describe your API?

Decorators on verbs/methods for fine grained access is what we’d discussed recently on the rest-interface mailing-list, do not hesitate to post your enhancements.

This project really deserves a new team…

By: Adrian

Adrian — Wed, 09 Apr 2008 14:59:50 +0000

@David, @Batiste: I’m sure that you can parameterize the decorators to make them return whatever you want…
I am using decorators in the modified rest-interface to secure some resource methods if needed (for example, GET does not require auth but POST yes, and so on) and from what I’ve seen, it’s just syntax sugar for encapsulating functions inside other functions, so you can parameterize plenty of stuff with it!

By: Adrian

Adrian — Wed, 09 Apr 2008 14:56:02 +0000

Ahhhh I understand now :)
As for rest-interface:
- I’ve added support for the OPTIONS verb (and can be extended to other verbs like HEAD, too).
- I removed the use of Django’s own serialization of model objects, using native Python facilities instead, such as simplejson, yaml, XML, csv, etc, using a simple dictionary object as input for all of them, which includes not only the data, but also metadata (messages, timestamps, etc), and can then serialize any kind of data (arrays, typically). This way resources can return pretty much anything.
- I’ve added some configuration values, with separate security checks for valid HTTP headers (they can be activated and deactivated in the settings file).
- Most important: I created a special resource which returns the complete API description, which I then use to generate API wrappers in Python, Ruby, PHP, even Objective-C :) This means that each resource describes the input and output they require (kind of a poor man’s WSDL, if you want)
- I’ve also finished the implementation of Digest Authentication (what a mess, geez! Now I understand why only big companies use it!)
- and finally I’ve also extended the django.test.Client class (featured in a previous post in this blog) with support for PUT and DELETE and OPTIONS and Digest Authentication,
- and added plenty of testing to all of this.
Phew. :) I’m sure it can be useful to others, and I hope to publish it as soon as possible!

By: David, biologeek

David, biologeek — Wed, 09 Apr 2008 14:34:29 +0000

Let’s call this coincidence greut ;)

I’m really interested in your enhancements, could you tell me more? Or maybe the rest-interface mailing-list is more appropriated? I hadn’t enough time yet to extract my own from my current project but it could be awesome to update the quite-dead rest-interface project.

@Batiste : your approach is really neat. It doesn’t handle different rendering, etc but it looks sufficient for some projects.

By: Adrian

Adrian — Wed, 09 Apr 2008 13:35:49 +0000

Hi David!
Thanks for your comment! Now that’s a coincidence, I’ve stumbled on your site today for the first time :) I’m using an enhanced version of the (excellent) rest-interface project which I hope to release to the public soon, adding some new features here and there.

By: David, biologeek

David, biologeek — Wed, 09 Apr 2008 13:09:39 +0000

@Adrian : I totally agree with you. I use the rest-interface project for all my apps now because that’s really more powerful when you think in terms of resources and representations.

@James : you react on details but the related issue is more interesting…

By: Adrian

Adrian — Fri, 04 Apr 2008 19:01:02 +0000

@James thanks for your comments; again, as I’m not a native English speaker I might *grin* be using the word in non-conventional ways. Sorry for that. Secondly, I’m not entirely arguing about a single example; I simply think that the choice of writing the name of the template at the end of the view is simply flawed, and that the tutorials should *also* point out other ways, which is not currently the case. As I pointed out at the end of the entry, it’s an architectural problem, not specific to Django, by the way.

By: James Bennett

James Bennett — Fri, 04 Apr 2008 17:11:48 +0000

So, the things that bug me in your arguments are twofold:

First, you rely to an extreme extent on the word “might”. Something “might” not scale well; another thing “might” cause repeated code. Relying on situations where something “might” happen might lead you rather far astray.

Second, you’re almost entirely arguing based off a single example from the Django tutorial, devoid of any further context; yeah, it doesn’t paramaterize return types or template names or refactor itself into a class to dynamically handle any feature you want out of it, but in a web framework oriented toward returning rendered HTML via HTTP, is it really so evil to have the tutorial use that as an example? You apparently managed to work out that if you want to do tons of other things, it’s easy enough to do so, so it can’t be that hard.

By: Adrian

Adrian — Fri, 04 Apr 2008 12:27:55 +0000

The “Resource” objects used in the Django REST project can have any number of methods in them, not only the __call__ method, so you can have some methods that return data and others that perform the serialization in whichever format you need.

Beware also of the fact that using objects means that you have an overhead in terms of instantiation and destruction, that you might not have using functions (however I don’t know that well the inner workings of the Python runtime, and the relative costs of the decorator vs. the OO approach). I should have mentioned this in the article, by the way.