简体   繁体   中英

RESTful APIs for Django projects/apps

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:

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.

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.

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

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.

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 )

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM