GSoC 2007 Status Update IV: Django REST interface

3 views
Skip to first unread message

Andreas Stuhlmüller

unread,
Jun 23, 2007, 1:40:48 PM6/23/07
to django-d...@googlegroups.com
This is the fourth weekly status update for my Summer of Code project,
a generic REST interface for Django [1]. Issues I worked on this week:

1. Authentication. I added authentication hooks to the Collection
class, an implementation of HTTP Basic and Digest authentication
(stateless, header is sent with each request), authentication tests
and a function that connects HTTP Basic auth with Django's User model.

2. Continued work on URL generation. It is now possible to overwrite
all URLs by subclassing Collection. The distinction between methods
that return URLs and methods that return URL patterns got clearer. The
URL generation part of the REST interface is still going to change a
lot.

3. Appropriate error messages. I added methods to JSONResponder and
XMLResponder that return mimetype-specific error responses which
include a human readable error message, application-specific errors
(e.g. missing ) and a machine readable status code.

According to my initial timetable, next week is reserved for writing
unit tests and documentation. Although not complete, I have already
written quite a few tests along the way. The main task will be to fit
these tests into Russell's unit testing framework. Another issue that
needs to be resolved next week is that authentication should allow
different levels of access to the same resource for authenticated and
unauthenticated users.

As always, criticism, ideas and suggestions are welcome!

Regards,
Andreas

[1] http://code.google.com/p/django-rest-interface/

David Larlet

unread,
Jul 13, 2007, 9:20:17 AM7/13/07
to django-d...@googlegroups.com
2007/6/23, Andreas Stuhlmüller <stuhlm...@gmail.com>:

>
> As always, criticism, ideas and suggestions are welcome!
>

Ok let's go :-)

First of all, thanks for your awesome work, I eventually take time to
review it and it sounds exactly what I expected. Here are some random
thoughts about the current implementation:

* About users, how can I handle django users' permissions? John
Sutherland had already done some work on django-crudapi [1] and it
could be interesting to allow this access control.

* About dispatch, why don't you use the __call__ trick? Joe Gregorio
uses it in djangocollection [2] and I find it really elegant. That the
way Jacob Kaplan Moss describes RESTful web services in django too in
the RESTful Web Services book [3] (which I recommend BTW).

* About functions' names, I'm not fond of CRUD names and I prefer to
keep an information on the HTTP verb in the function name but it's
maybe personal.

* About verbs, I know this is not really GSoC related but what is the
recommended way to handle fake PUT and DELETE from a browser? The
HttpMethodMiddleware[4]? Maybe a simple form/deletion in the polls
application will be an interesting example for a real django case.

Best regards,
David

[1] http://django-crudapi.googlecode.com/svn/trunk/views.py
[2] http://djangocollection.googlecode.com/svn/trunk/djcollection/views.py
[3] http://www.crummy.com/writing/RESTful-Web-Services/
[4] http://www.djangosnippets.org/snippets/174/

Andreas Stuhlmüller

unread,
Aug 3, 2007, 9:49:11 AM8/3/07
to django-d...@googlegroups.com
On 7/13/07, David Larlet <lar...@gmail.com> wrote:
> * About users, how can I handle django users' permissions? John
> Sutherland had already done some work on django-crudapi [1] and it
> could be interesting to allow this access control.

Good question. I would subclass one of the authentication classes,
e.g. HttpBasicAuthentication, and add a has_perm() check dependent on
the request method to is_authenticated().

Currently, REST authentication is independent from Django's
authentication middleware. It might make sense to move most of the
code in HttpBasicAuthentication and HttpDigestAuthentication to
django.contrib.auth.backends and to let the middleware do most of the
work.

> I'm not fond of CRUD names and I prefer to keep an information on
> the HTTP verb in the function name but it's maybe personal.

I chose the CRUD names as they better describe what the methods
actually do, but if the consensus is that it is more important to
highlight the HTTP method, I will change this.

> * About dispatch, why don't you use the __call__ trick?

Fixed, thanks for the pointer.

> * About verbs, I know this is not really GSoC related but what is the
> recommended way to handle fake PUT and DELETE from a browser? The
> HttpMethodMiddleware[4]? Maybe a simple form/deletion in the polls
> application will be an interesting example for a real django case.

Yes, I recommend HttpMethodsMiddleware [4]. I just added a "delete"
button to the template example and verified that it works if you add
HttpMethodsMiddleware to your middleware classes.

Thanks for your comments!

Regards,
Andreas

[4] http://www.djangosnippets.org/snippets/174/

David Larlet

unread,
Aug 6, 2007, 4:08:54 AM8/6/07
to django-d...@googlegroups.com
2007/8/3, Andreas Stuhlmüller <stuhlm...@gmail.com>:

>
> On 7/13/07, David Larlet <lar...@gmail.com> wrote:
> > * About users, how can I handle django users' permissions? John
> > Sutherland had already done some work on django-crudapi [1] and it
> > could be interesting to allow this access control.
>
> Good question. I would subclass one of the authentication classes,
> e.g. HttpBasicAuthentication, and add a has_perm() check dependent on
> the request method to is_authenticated().
>
> Currently, REST authentication is independent from Django's
> authentication middleware. It might make sense to move most of the
> code in HttpBasicAuthentication and HttpDigestAuthentication to
> django.contrib.auth.backends and to let the middleware do most of the
> work.
>

Sounds good to me.

> > I'm not fond of CRUD names and I prefer to keep an information on
> > the HTTP verb in the function name but it's maybe personal.
>
> I chose the CRUD names as they better describe what the methods
> actually do, but if the consensus is that it is more important to
> highlight the HTTP method, I will change this.

Eventually, I'm not against CRUD names but maybe we could be
consistent with rails ones?

> Thanks for your comments!
>
Thanks for your answer :)

Regards,
David

Reply all
Reply to author
Forward
0 new messages