Hi , Sorry for late reply, there's lot of college work on hand.

Thanks for creating the two examples! I took a quick look at them and it looks like both frameworks are pretty easy to use if a resource is based on a typical Django model. The Mailman resources OTOH are not retrieved from a database but from another API -- Mailman's core REST API that is only served locally (postorius uses the mailman.client library to access that data). Which of the two frameworks would you consider more flexible if you want to get your data from anything else but a Django DB model (I *think* Tastypie has different classes for model resources and everythingelse-resources)?

I looked into Tastypie and yes the model resources is just more tightly wrapped class which focus on django ORM and then there's this resources class which could be used for non orm models. I also went through a similar example on Tastypie, for using nosql db for resources. Here is a link to the example I found on Tastypie docs [0] . They are linking Riak for data resources, and Riak client used here communicates with core Risk for data sources with the APIs.

So, I believe similar thing could be achieved with our project.

...

*$ curl http://127.0.0.1:8080/formpost/ -H 'Accept:text/html'

The Django-rest-frameworks API's returns web browsable representation of the data by default :)

Sounds nice! :-)

...

So , the confusion I am facing here is that the Postorius is already mature and stable app and while playing with the two frameworks for API's what I figured out is that if I opt for django-rest-framework , I would need to write new Views ? But if I go for TastyPie , I won't have to touch the existing Views and write authenticated API's.

Hence to implement authenticated API's , which one would be better ?

Hard to say - judging by how they're used in the examples, both look good. But there are some more things you might want to consider before choosing one:

Authentication methods Which auth methods are provided out of the box by the frameworks? And which one(s) would you like to support (OAuth(2), BasicAuth over SSL, ...)? I guess choosing and implementing authentication could become one of the major sub-tasks of that project.

Talking about authentication, django-restframework has a wrapper for OAuth2 out of the box, but I will have to check how to use non form data sources. I know there must be a solution for that, but then again in django-rest framework REST APIs are handled from the views.py. I don't really want to fiddle with existing views.py in Postorius. Maybe we could discuss more about this , accounting what would be better in the long run. Personally I would be sticking to Tastypie for authentication as well. If we plan to support Oauth2 , it could also be achieved with Tastypie. Couple of days back I saw some similar examples on github. I would try to provide some examples on the topics to support my proposal. Hopefully I would be able to do that by this weekend .

Support for Django 1.5 and Python3:

Isn't the support for Python 3 just experimental in django 1.5 .? And neither of the two third party frameworks support python 3 fully in their current release. Django rest framework has some amount of experimental support but not sure about Tastypie.

At some point in the not so fare future mailman and postorius will be ported to Python3. Django 1.5 already supports Python3, so it would be a bonus point if the rest framework supports it, too (or if their developers are making efforts to do so...). I know the support for python 3 is essential to the project, but as of now sticking I would prefer to sticking to Python 2.7.x for now. I would be having a month in hand before official GSOC CODING period starts. During this time I would be getting stared with the project so that there would be some substantial code ready before official coding time starts. I guess its roughly two months from now , so if there's a release for these frameworks with python 3 support . Porting it wouldn't be that much of an issue.

Another idea (not sure if it's a good one): Maybe also take a closer look at Django's class-based views. They are capable of routing requests to the same URI to different dispatch methods, depending on the HTTP method. So that might be also be an interesting option.

Yes, this is similar to what class based views in django-restframework offers. To be honest, I don't really have much idea about django class based views.I am looking into this and I would let you know.

Also I have couple of other thinks I would like to discus. Maybe we could discuss more about this over the irc.

Regards!

Rahul