I’m glad you’re open to collaborating! I think together we will come up with very robust solution. Have you given thought as to how you want to proceed?

(Incidentally, I think your English is excellent–better than many native speakers I know… but don’t hesitate to let me know if I am ever unclear.)

Here are a few preliminary thoughts I have. Your blog post prompted me to make a few quick updates to my existing code to factor out the model specific approach more, so that its now ready (I think) to allow developers to define resources that are not directly tied to models. If you like the basic approach I took, we could use this as a starting point, just let me know if there are areas that you would like clarified, or if there are areas you think should be cleaned up more. I also believe that nothing is set in stone and would be prepared to start from scratch also if that makes the most sense.

Either way, we should probably start a new project site and deprecate the one I started. The Google project hosting seems to be easier to use than Source Forge, but I suspect that you can’t just rename an existing project. Do you have a preference?

My knowledge of Ruby on Rails comes purely as a spectator–I haven’t used it yet myself, although that might happen as part of ongoing research into the ideas they’ve come up with. And as I said, because I am also new to the REST philosophy, and still very new to Django, and because you seem to be more experienced with Django at least, I would be happy to follow your lead on this project. Besides, my best ideas may already be in the existing code, while I think you have a strong vision for how to take it to the next level and beyond.

Also, I have a significant project in the works for which I am planning to use Django, and I could use the developing REST API underneath so we would have that as an extra reality check.

Let me know your thoughts on this. I think I am ready to proceed, even if its slowly at first. I’m really excited about the possibilities here.

Feel free to contact me directly at my email address below.

adam smith
ajs17@cornell.edu

If my ideas sound similar to your current thinking that’s because I learned a lot reading your blog posts on REST and Django.

In particular, I think that the urlpatterns are pivotal to making REST work elegantly in Django; because the regular expression syntax is so dense and because there may be so many RESTful urls in an application, this seems like a key place to ease a developer’s burden

Yes, we need to think about URL refactoring ideas such as Nicolas Lara’s before implementing the REST/API proposal. On the other hand, RegEx URL patterns are one of the things I really like about Django. We might end up providing shortcuts for the most common REST URL patterns while leaving the basic URL functionality unchanged.

I had only started thinking about how to configure less model-centric resources, to which you seem to have well formed ideas.

I want to point out that, although I describe one specific approach that connects models, urls and APIs (the Resource/ModelResource class approach), nothing is set in stone yet. There are probably many ideas I haven’t even considered and once we start writing code, new ideas will inevitably crop up.

I would definitely like to work with you and I have mentioned this in a comment on the SoC website. Collaboration makes a lot of sense: You seem to have spent more time thinking about REST in general, you are a native English speaker (I would not want to read documentation written by myself) and you know things about web development that I don’t (my knowledge of Ruby on Rails is quite shallow).

This is a really nice overview and proposal–I wish you had written it a few months ago! I didn’t know about many of the existing attempts to do REST more easily in Django.

Your ideas sound very close to my current thinking–well, actually, I think you are many stages beyond my thinking at this point. Although I started out just trying to leverage the existing model/generic views code in Django, I have more recently come around to the idea of a more general REST interface that the model/generic view approach would implement, and I had only started thinking about how to configure less model-centric resources, to which you seem to have well formed ideas. I was also trying to think about how to respond in different formats, for which again, you seem to have a pretty well developed ideas for how to do this.

I have been using the Ruby on Rails approach as a source of ideas for evolving my own code, as it seems to be a pretty straightforward and relatively mature implementation. And there might be opportunities for sharing knowledge between the two communities. Otherwise, my main concerns have been using a test driven approach to coding it and trying to figure out how to make it as easy as possible for developers to implement the approach. (That was the other nice thing about focusing on models and generic views, much of it could be introspected automatically.)

For example, I think it would be great to see code like your poll_api example inside a Python module that follows a name/location convention like urls.py and other Django modules, then programmatically build the urlpatterns from that (or at least, have that as an option that can be overridden for more complex implementations) in a way that injects as little code as possible into urls.py and elsewhere so that the code stays clean and people can start using it productively without a steep learning curve or drastically changing how they use Django already. In particular, I think that the urlpatterns are pivotal to making REST work elegantly in Django; because the regular expression syntax is so dense and because there may be so many RESTful urls in an application, this seems like a key place to ease a developer’s burden, by finding a way to generate these automatically from other configuration settings or conventions.

So, as I think my approach is very compatible with what you are proposing, would you like to work together to develop this into a full fledged Django contribution? As your ideas are significantly ahead of mine, and you seem to have significantly more Django experience than I, I would be glad to have you be the project lead. Or, if you want to work on your own implementation alone, but plan to produce working code in the near future, I could also use the time I would have spent developing my code and spend it testing what you produce, filing bug reports and suggestions, generating documentation, etc. For me, the important thing is to learn Django in more depth and begin building RESTful applications, and I’d like to put my energy behind the best approach, even if that turns out not to be mine. I also want to give back to the community in the way that is most appropriate for my level of knowledge and experience.

If you are so inclined, my blog posts, which I link to from my project site, chronicle the process I have gone through so far to develop the code. My last blog post on the subject from a few weeks ago goes into many similar ideas to what you have in your proposal, and the django restful-model-views site itself was updated to reflect those ideas. The code itself is strong in places–its pretty fully unit tested, and some aspects of it are well thought out and well implemented I think, and could be a good starting point for developing the REST API you have envisioned. At the very least, it might be food for thought, such as the approach I took to organizing the view code for example.

If you are interested in working, please feel free to contact me directly.

adam smith
asmith@agile-software.com
http://code.google.com/p/django-restful-model-views/