RESTful web services for Django

[Andreas Stuhlmüller]

As part of this year's Summer of Code, I proposed to implement an easy
way to make existing Django models available via RESTful APIs. My
proposal [1] got approved, my mentor is Malcolm Tredinnick. I would be
glad to read some feedback from those of you who are interested in how
REST-based web services with Django should look like.

My work consists of two major parts:

a) Easily configured Create/Read/Update/Delete (CRUD) method
access patterns for models.

and

b) Resources that don't correspond 1:1 to models.

I made both part of my proposal since I would like to see REST
implemented in a way that makes it easy to seamlessly use both model
resources and custom resources that may not necessarily be related to
individual models.

I know three projects that overlap with the first part of my proposal.

1. djangocollection
http://code.google.com/p/djangocollection/
The djcollection app provides a set of generic RESTful urls for all
the models of a project and a GenericCollection class which uses
Django's generic views (and therefore templates) to make models
CRUD-accessible.

2. django-crudapi
http://code.google.com/p/django-crudapi/
Provides a set of catch-all urls and CRUD functions that make the apps
of all models of a project CRUD-accessible, uses Django's serializers
to return json or xml.

3. django-restful-model-views
http://code.google.com/p/django-restful-model-views/
Adam Smith follows an approach similar to the one I proposed (an
abstract Resources class and a ModelResources class for model-bound
resources). He uses a lot of introspection to automagically create url
patterns for all models that should be available. Adam intends to use
Django's generic views (not implemented yet).

These projects look like a good point to start, but they don't seem to
pay much attention to security questions like which data should be
accessible, which CRUD actions possible and which model fields
visible. To my mind, these should be available as settings similar to
the urls.py example shown in my proposal.

Other questions that need to be resolved include:
- Should URLs be generated automatically?
- Do we make use of the existing generic views (as in 1. and 3.),
use serializers (2.) or make both an option?
- How does the interaction between the API and authentication
look like? If we want to allow different levels of access for
authenticated and unauthenticated users, how should this be
configured?

As far as part 2 of the proposal is concerned, the main question is
whether (and how) we can make creating these resources easier instead
of just changing the type of work that is required to implement them.

I will try to come up with a concrete example that allows me to
illustrate the different ideas I have, both regarding part 1 and part
2 of my proposal, and that makes it easier to discuss these ideas.

According to Google's timetable, I should start coding on May 28.
However, during the two weeks before the SoC midterm evaluations
on July 9 I am writing eight exams and therefore I don't expect to get
much coding done. I'll make a bit of an early start to make up for this.

Andreas

[1] www.aiplayground.org/artikel/improving-django/

[David Larlet]

First of all, thanks for your GSoC proposition, it looks very
interesting and I hope it will be integrated to the trunk at the end
of the summer because I really need it ;-).

2007/5/8, Andreas Stuhlmüller <stuhlm...@gmail.com>:

>
> I will try to come up with a concrete example that allows me to
> illustrate the different ideas I have, both regarding part 1 and part
> 2 of my proposal, and that makes it easier to discuss these ideas.

I agree with you, it's hard to discuss high-level abstraction without
a concrete example. I have collected all REST relative links during
the last months on the feature grouping page:
http://code.djangoproject.com/wiki/FeatureGrouping#WebservicesREST

Hope it helps, I'm waiting for the example to comment your choices.

David