RESTful APIs for Django projects/apps

Question

What do you prefer when you want to "RESTify" your Django project in Django?

I came to the conclusion that there are really three options to do that:

• django-piston http://bitbucket.org/jespern/django-piston/wiki/Home
• django-rest-interface http://code.google.com/p/django-rest-interface/
• django-restful-resources http://watchitlater.com/blog/2010/02/django-restful-resources/

Right way to do this for me would be to try all of'em and pick the one that is best for me, so meanwhile I'd like to hear yours...

Thanks.

Keven

Answer 1

I'm most familiar with django-piston, so I would naturally steer you in that direction.

A quick glance at the other two, though, indicates that django-rest-interface does nothing more than expose models as resources, and that django-restful-resources is some guy's one-off attempt at the same.

Piston, if I recall correctly, grew out of bitbucket.org's own site development, and allows a lot of flexibility - you can return almost any object from your resource's access methods, not just model instances, and it will be properly encoded. It also has built-in support for some nice features, like form validation (if you can get it to work right, anyway) and request throttling, among other things.

Soundboard

Answer 2

With the new class-based generic views in django 1.3 it will be super-easy to implement your own rest interface, with custom serializers and deserializers, replicating the almost complete piston's implementation using just stock code. I made a View(1.3)-based rest module in 500 lines of code, with generic RESTful resource class and sub resources, natural key support for associations, json and XML serialization and more. the module is really tailored upon my app's requirements

I did it to overcome a couple of limitations in piston's code, like having a query set modified (e.g. With .values(...)) before the handler calling .get() on it, or not being able to use a model's method in serialization.

If you do it as you need it, in a couple of days you'll have a working set of classes and mixins, that you will fully understand and be in control of.

Shrewd

You can try my own restful views at github.com/rewritten. It's not thoroughly tested and it could be good to get some more eyes on it. – Shrewd

Answer 3

As the "some guy" who wrote django-restful-resources I would like to clarify why it exists. It is NOT an attempt to expose models as resources, rather it is a means of allowing a single URL to be mapped to a number of different handler methods, one per HTTP verb. That's all. It can be used to expose model objects, but it can also be used to expose services as resources or anything else that you want to interact with via a single URL and HTTP verbs. If you are looking for a more full-featured solution then by all means go with Piston.

Serpentiform

Hi Tom, thanks for taking time and answering to this question. Could you please enlighten me about HTTP verb-thing? Thanks. – Keven

Hi exalted, HTTP verbs (or HTTP methods) are GET, POST, PUT, HEAD, DELETE, OPTIONS and TRACE. You can find really good descriptions of how to use them to write RESTful web services at the following links: - w3.org/Protocols/rfc2616/rfc2616-sec9.html - amazon.com/REST-Practice-Hypermedia-Systems-Architecture/dp/… - watchitlater.com/blog/2009/11/… (shameless plug) – Serpentiform

Answer 4

As mentioned by eternicode, django-piston is excellent. It's mature, well featured and has a good community behind it. It does seem to be lacking much ongoing development at the moment, although there is talk of a community driven fork, so that may change.

django-tastypie is also well worth a look, and seems to have a lot of impetus behind it at the moment.

I've also just released another option that's worth considering: django-rest-framework. There's a couple of really nice features behind it such as the API auto-documentation.

It uses Django 1.3's class based views, as mentioned by saverio, which means you can just drop in some of the MixIn classes it provides, without having to use the framework outright. (For example adding HTTP content negotiation for serializing output to multiple types)

Sienkiewicz