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/

2007/6/23, Andreas Stuhlmüller <stuhlmuel...@gmail.com>:

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/

On 7/13/07, David Larlet <lar...@gmail.com> wrote:

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 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.

Fixed, thanks for the pointer.

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/

2007/8/3, Andreas Stuhlmüller <stuhlmuel...@gmail.com>:

Sounds good to me.

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

Thanks for your answer :)

Regards,
David